audio echo on hd audio device (hades nuc), bios fails to post dragons

[LShuh]

We have several of these in service and they all exhibit this behavior. Plug in a nice pair of headphones, and the audio output to the jack sounds like it has a weird echo/reverb. All drivers up to date using Intel tool. All mic inputs disabled.

I am wondering if BIOS forgot to disable line in and the dangling pins are receiving crosstalk from adjacent playback and mixing it back in. Anyone else have this issue?

Hardware: HNKBLi70.86A.0029.2018.0222.1606

Whomever marked this as 1/5, please let me know what information you'd like to see in this tracker to help.

[idata]

Hello, sklk_lev. Thank you very much for sharing your issue with the Intel Communities Team. I will be more than glad to assist you.

In order for me to assist you better, please provide me with the .txt file that the https://downloadcenter.intel.com/download/25293/Intel-System-Support-Utility-for-Windows- System Support Utility will generate. To attach a file, you must click the "Attach" option on the bottom right-hand corner of the response box.Furthermore, I would like to know the model of the headphones you have tested? In addition, is this happening with every sound coming from the system(eg. music, video, etc..)?Antony S.

[LShuh]

Hi, Anthony-

External audio devices such as Jabra Speak 410 (USB) do not exhibit this behavior. I am using Sennheiser HD280 Pro. My coworker is using Bose QC35 ii - and they both work flawlessly with any other audio device (like iPhone). Streaming to Google home doesn't exhibit this behavior either.

We don't see the line in as an option to disable in Windows.

===Here be dragons===

I'm sorry that the attached dump is after a power cycle, but our building failed overnight, and our backup batteries ran out on both, causing them to hang during POST. We didn't get a dump prior to the power outage. The main LED comes on + two greens, one of the greens blinks a few times, and then it turns off and retries. We had to take the the batteries out of them to get them through POST because they don't reliably come back when the battery is installed.

If you have a debug BIOS for me to load and where to plug in for a tty console, I could get a dump - I'm certain this will reproduce when I put the batteries back. As I mentioned, we have two of these. Also, if you have a port 80 board and the LPC bus is exposed on the NUC, I could get the POST code where it hangs. I suppose it's prior to 90h because the keyboard num lock is inop when it hangs.

I'll let you know if it comes back, but there be gremlins here in BIOS. Please forward the dump and info to the BIOS team, and have them review their code wrt to the audio and the power issues. Sorry to grow the case on you, but we are relying on these as our workstations for development here. Our older NUCs don't exhibit this behavior, and we'd like to keep buying more for new hires, but we'd like the gremlins gone first.

Oh, and the echo disappeared for me after the BIOS reset with the battery unplugged.

[Chris_V_Intel]

Also your BIOS is REALLY old.

Here's the new one: https://downloadcenter.intel.com/download/28038/BIOS-Update-HNKBLi70-86A-?product=126141 Download BIOS Update [HNKBLi70.86A]

Check it out and let us know.

[LShuh]

Sure, 02/22/2018 seems "really old" (6 months), but we don't update unless something is broken and obviously fixed in the rev notes.

Found something possible:

Fixed the issue where the system would not power on correctly when the power cord is pulled and the BIOS option "After Power Failure" is set to either, Last State or Power On.

That was released less than a month ago. Sorry for not being on the bleeding edge.

[LShuh]

Ok, BIOS updated to 0048. Plugged in the battery, rebooted. Everything looked ok. Pulled the power. It doesn't come back.

Either the issue wasn't fixed in BIOS 0047, the fix was accidentally backed out in BIOS 0048, or this is a different failure mode altogether.

I'd need a port 80 to be more specific in where the hang is since this is prior to PCIe/video initialization. Is there a console/debug BIOS on the NUC?

[LShuh]

And... the echo is back.

[Chris_V_Intel]

Bugger!

I know 6 months isn't old, but when the product has only been out for 3...

There is not a console/debug, but when you say "it doesn't come back", I'm assuming you mean it doesn't boot when you apply power?

I just double-checked it on BIOS 0048 and as long as the power state in the BIOS is set "last state" or "power on", it worked for me. I pulled the plug, plugged it back in a few seconds later and it booted right back up.

I'm wondering if the battery might introduce some oddities, both in the power on and the echo? I know it shouldn't but who knows.

Can you explain a bit more about your setup?

[LShuh]

Yup. I did try that BIOS setting, to no avail. When I say "it didn't come back" I mean POST does not complete. I don't think it gets far enough in POST for PCIe init since there is no video. Keyboard/num lock isn't responsive, so it's not that far. For all I know, the ME has crashed. Hard to say without the port 80 code and a debug bios. I assume nvram is wiped when I pull the battery?

FWIW the echo/garbling/reverb goes away after NVRAM reset, but can come back. I did notice that as windows boots, there are a few clicks on the headphones, sounds like muxes flipping - maybe driver loads, probably innocuous.

The setup is 2x DP connections, USB keyboard, wireless logitech mouse with their dongle. Oh, and the headphones. Even if I unplug everything, unless I remove the battery, I can't get it out of that state. That would point to early init, not sequencing. I can check the rails out as well if that would help. I'm speculating here. I don't have an LPC/port80 adapter here, and you probably depopped those connectors for production anyways.

FWIW, when it's in this state, unplugging everything doesn't change the behavior. If you send me a debug bios and where the UART pins are, I could probably take a console dump for you, if it gets that far. I'm sure we could find a spare UART dongle.

We do have NDAs in place if you don't want to make debug BIOS and UART info public, just email me, and I'll get the debug info for you. You can also give me a call.

[MLevi]

I'm intrigued by the echo problem.

Might be related to the microphone array.

see:

I know it's not the major issue that you're trying to resolve, just a thought.

[LShuh]

I haven't unplugged the microphone array, but I have disabled it in Windows, to no avail. Might try that next time it reproduces. It's not predictable when the echo starts yet - I haven't correlated it to any specific trigger event/program/sleep/whatever.

[LShuh]

To add a little mystery, I went through a little experimentation this morning, and after resetting all BIOS settings to default, and setting only the option to "Power On" after loss, I put the battery back in, booted to windows login screen and pulled the power. The issue continues to reproduce again.

When I say "pulled the power", I do mean the 19V plug, not the AC, so communications with the supply would error out at that point, instead of sending any powerloss signal. I understand that this is different than the outage that caused my issue in the first place, but it's how I've been testing if that helps.

Additionally, after pulling the battery again, when windows came up, the echo is back. Previously, doing this made the echo go away. It's the first thing I'm testing once it boots, before any other programs start. It seems random and uncorrelated to any event, including nvram resets.

I also tried disabling ASPM, and other power controls as well, to no avail. The issue continues to reproduce. If there's a micro/cpld doing power sequencing here, the issue might be buried in that code, or in communications to the po

[LShuh]

Oh, yeah, and I unplugged the mic array when it reproduced, and it had no effect, as expected. The echo/reverb mixin sounds like the music which is playing, not ambient noise.