NUC7i3BNK Bitstream Lossless Audio

elfurbe · February 5, 2017 at 4:25 AM

I upgraded my NUC from a Haswell (NUC5) to the new Kaby Lake (NUC7), mostly to get hardware 10bit HEVC at some point in the future. I restored my backup from the NUC5 to the NUC7 and validated all my settings. Unfortunately, I'm no longer able to bitstream lossless audio. Standard DD and DTS work fine, but TrueHD and DTS-HD generate no sound at all. My receiver acts as if no sound is being sent. If I disable the lossless options in settings, TrueHD seems to output as LPCM and DTS-HD downgrades to core, as expected.

The only oddity I see that's obvious is that X seems to think it's on DP1 rather than HDMI1, but it looks like it considers them clones so maybe that's normal here. Also my xrandr output shows an incorrect "Broadcast RGB" setting, it should be forced to "Full" by autostart.sh. This was a previous Kodi best-practice for proper black levels (TV set to limited, X output set to full, Kodi set to limited), but perhaps 17+newer GPU has created some synergy here that I'm unaware of and "Video 16:235 pass-through" is expected now. I only mention it in case it's further indicative of some problem with the output device, the audio problem is the only thing I'm intending to report here.

System Details:

NUC7i3BNK (i3-7100U, Intel HD Graphics 620)
Using the HDMI output
LibreELEC 7.95.2

Logs and whatnot:

Debug log for attempted playback (DTS-HD, I can do TrueHD as well if you like): anKbafCM
Audio/Video settings screenshots attached
Mediainfo for file used on test: WkZKwXA5
dmesg: ipAmGTqT
lspci: quY8Fwy3
lsusb: 8uCq4Qbv
xrandr: xrandr - Pastebin.com

Let me know if there's anything else I can provide that would be helpful.

Thanks!

**Klojum** · February 5, 2017 at 8:12 AM Official Post

Quote from elfurbe

TV set to limited, X output set to full, Kodi set to limited

Call me stupid, but why would you limit your devices when they are probably capable of doing full colors? Limiting the black colors will give you a washed up greyish layer over your display. I would disable the limitation and always go for full colors, on the htpc as well as the TV.

You may have to up the brightness/contrast on your TV, but in the end the colors come out better.

elfurbe · February 5, 2017 at 3:52 PM

Quote from Klojum

Call me stupid, but why would you limit your devices when they are probably capable of doing full colors? Limiting the black colors will give you a washed up greyish layer over your display. I would disable the limitation and always go for full colors, on the htpc as well as the TV.

You may have to up the brightness/contrast on your TV, but in the end the colors come out better.

I'd really prefer not to derail my bug report with this topic, but since you insist and you're a moderator to boot: you're stupid.
Video levels and color space - Official Kodi Wiki

I don't disagree that the answer is not intuitive, but it is nevertheless the answer. I assure you the picture on my reasonably-calibrated Kuro is far from "washed up" and "greyish", in fact a small but dedicated choir of angels sings a triumphal verse each time I power it on, which you'd think would become tiresome but so far has not. If you'd like to continue having this particular fight, send me a DM or open a different thread called "elfurbe is a black-level heretic and must be destroyed" and I'll fight with you there to the best of my ability, but I'm more concerned about my audio problem in this one, if you please.

Cheers!

**ozolli** · February 5, 2017 at 4:27 PM

Quote from elfurbe

Also my xrandr output shows an incorrect "Broadcast RGB" setting, it should be forced to "Full" by autostart.sh. This was a previous Kodi best-practice for proper black levels (TV set to limited, X output set to full, Kodi set to limited), but perhaps 17+newer GPU has created some synergy here that I'm unaware of and "Video 16:235 pass-through" is expected now.

Yes it is on Intel GPUs. It's basically a "Full" mode which also implements the Intel zero copy approach to directly render the decoded NV12 surface.

elfurbe · February 5, 2017 at 7:45 PM

Quote from ozolli

Yes it is on Intel GPUs. It's basically a "Full" mode which also implements the Intel zero copy approach to directly render the decoded NV12 surface.

Well there you go. So never mind that, then.

skipp · February 8, 2017 at 10:34 AM

Hello,

the bug with the HD Audio is well known. It is a problem of the intel drivers. Some people report they have the same Problems under Windows 10 too! In KOdi froum is al long thread about this problem.
Intel Apollo Lake

I have also the same problem and hope that intel will fix this bug.

elfurbe · February 24, 2017 at 10:59 PM

Just saw this today: Download HDMI 2.0 Firmware Update Tool for Intel® NUC Kit NUC7i3BN, NUC7i5BN, NUC7i7BN, NUC6CAY

I'll try booting Windows on my NUC and applying this tonight and we'll see if our long Kaby Lake nightmare is over.

elfurbe · February 25, 2017 at 8:11 PM

Quote from elfurbe

I'll try booting Windows on my NUC and applying this tonight and we'll see if our long Kaby Lake nightmare is over.

Nope.

Achilles · April 9, 2017 at 10:12 AM

Quote from Klojum

Call me stupid, but why would you limit your devices when they are probably capable of doing full colors? Limiting the black colors will give you a washed up greyish layer over your display. I would disable the limitation and always go for full colors, on the htpc as well as the TV.

You may have to up the brightness/contrast on your TV, but in the end the colors come out better.

Because you do not want to scale the original limited color range of the source material if you are a hard core purists--losing BtB and WtW video signals. Another reason is if your common denominator needs to be limited when using an AV receiver and outputting to one input on the display.
[hr]

Quote from elfurbe

I upgraded my NUC from a Haswell (NUC5) to the new Kaby Lake (NUC7), mostly to get hardware 10bit HEVC at some point in the future. I restored my backup from the NUC5 to the NUC7 and validated all my settings. Unfortunately, I'm no longer able to bitstream lossless audio. Standard DD and DTS work fine, but TrueHD and DTS-HD generate no sound at all. My receiver acts as if no sound is being sent. If I disable the lossless options in settings, TrueHD seems to output as LPCM and DTS-HD downgrades to core, as expected.

The only oddity I see that's obvious is that X seems to think it's on DP1 rather than HDMI1, but it looks like it considers them clones so maybe that's normal here. Also my xrandr output shows an incorrect "Broadcast RGB" setting, it should be forced to "Full" by autostart.sh. This was a previous Kodi best-practice for proper black levels (TV set to limited, X output set to full, Kodi set to limited), but perhaps 17+newer GPU has created some synergy here that I'm unaware of and "Video 16:235 pass-through" is expected now. I only mention it in case it's further indicative of some problem with the output device, the audio problem is the only thing I'm intending to report here.

System Details:

NUC7i3BNK (i3-7100U, Intel HD Graphics 620)

Using the HDMI output

LibreELEC 7.95.2

Logs and whatnot:

Debug log for attempted playback (DTS-HD, I can do TrueHD as well if you like): anKbafCM

Audio/Video settings screenshots attached

Mediainfo for file used on test: WkZKwXA5

dmesg: ipAmGTqT

lspci: quY8Fwy3

lsusb: 8uCq4Qbv

xrandr: xrandr - Pastebin.com

Let me know if there's anything else I can provide that would be helpful.

Thanks!

Display More

Intel needs to update the drm-tip drivers from what I understand. 98797 – BXT - HDMI - HD audio passthrough dont work

I am quite confused with what changed with the latest NUCs starting with Skull Canyon when it comes to the different modes for xrandr Broadcast RGB. It seems as if though Video 16:235 passthrough no longer functions. I made this post over on the Plex forums covering this issue as well as any other issues for Apollo Lake and Kaby Lake NUCs

rduke · April 9, 2017 at 1:30 PM

Same problem with an NUC7i3BNK here, too, regarding the bitstreaming of HD audio formats. Installed Windows 10 last Thursday to confirm it's somewhat related to the DP to HDMI conversion chip's firmware. Initially no HD-bitstreaming worked in Kodi under Windows, applied the 1.66 Megachips firmware update which fixed it there. As stated by the OP in this thread this doesn't help with LibreELEC though. Guess we'll have to wait for an updated driver for Linux or something along those lines.