I experienced the following issues in my NUC6CAYH, lack of support for DTS-HD-MA and other HBR audio file formats, lack of support for PCM audio at 192/24 encoding, applying the latest firmware and drivers limited the gizmo to 96/24 audio, etc.
After some proofs I discovered a couple of things:
If you start playing HBR audio and then turn off the TV or monitor, my receiver started to bitstream audio at 192/24 effortlessly, even the so-called HBR file formats. The receiver correctly detected the HBR formats and worked ok.
If I turned on the screen (a Samsung 4K Smart TV), the sound went mute. Turning off the TV allowed to recover the audio.
I suspected either a bandwidth issue with the HDMI 2.0 LPSCON implementation or a case of just awful driver implementation.
Then I tried to use the ASIO4ALL drivers, which are sort of a universal ASIO solution for sound devices that do not come with a manufacturer supplied ASIO driver. It enables the audio software to get direct access to the hardware, bypassing all the WDM stuff in between.
And guess what?
Using the ASIO4ALL drivers, I can play audio at 192/24, even multichannel audio (8 channels). The problem with this approach is that the audio decoding is being done in the NUC's CPU, so in Task Manager I could see CPU loads of up to 70% when decoding a 6 channel SACD ISO file.
The receiver gets LPCM audio up to 192/24 in 8 channels.
So, I defaulted the audio software player to use the ASIO4ALL drivers and decided to waste no more time trying to make WASAPI work (I'm using Jriver MediaCenter 23).
By the way, I'm using the latest Intel drivers, which are limited to 96/24 audio. The ASIO4ALL drivers don't seem to care about this, playing audio at 192/24 just fine, although with heavy CPU load.
So, here goes a question to the Intel guys: Is this a hardware limitation or a software driver limitation? How is it possible that using a third party supplied ASIO drivers enables the NUC to do things that seem impossible with the Intel-native drivers?
By the way. I also discovered that the problem with HBR audio decoding is due to the poor ARC implementation in the Samsung Tizen 4k TVs. The ARC signal can be received by the TV as either PCM or bitstream, but the return audio signal can be only PCM, Dolby Digital, DTS or Dolby Digital +.
I guess that is why HBR encoded files play flawlessly if I turn off the TV: HDMI audio no longer uses ARC, it starts being decoded by the receiver.
The only alternative that I found is to use an HDMI audio extractor and splitter called HD Fury. This splitter detects the EDID info of each device that it is connected to and delivers what the device requires. Nice, but at 150 USD it seems to be a bit too expensive way to solve the 130 USD NUC's problem.
Since I use the NUC mostly for audio, I can also leave the TV turned off and control the Jriver Media Center software via its web server or it's Android app and get HBR support via WASAPI. But this is somewhat cumbersome.
So, I suppose that the life expectancy of my NUC will be reduced by the heavy CPU load while playing multichannel HD audio, but at least I can still use the darn thing.
Message was edited by: Mirko Torrez Contreras