Unfortunately that doesn't help me much.
Until they'll release an official announcement I don't realy have faith in this problem getting solved!
I'm considering to move to Ubuntu in order to solve this thing (NO THANKS TO INTEL!)
Is there any news regarding the support of DTS HD. I was one click away of buying the Asrock N3700-ITX mobo but happily i'd check this forum and then discovered no DTS HD was supported. I'm upgrading from my Zotac AD02 with a AMD E-350 APU with HD6310 graphics and even that old board is able to passthrough DTS HD.
I'll wait a few weeks and if no drivers are available i'll go for another AMD based mobo then, which i really regret.
The engineers are considering the option but there is no official documentation about new releases on this NUC. We will need to wait a little more.
Its been two weeks since we heard some news from you. Any updates?
The http://ark.intel.com/compare/89189,89190 Skylake NUCs (in addition to http://ark.intel.com/compare/83257,83255,87570 Broadwell NUCs) seem to explicitly support https://en.wikipedia.org/wiki/DTS-HD_Master_Audio DTS-HD Master Audio and https://en.wikipedia.org/wiki/Dolby_TrueHD Dolby TrueHD.
Could it be that the Intel driver might still be updated for Windows, or was it a hardware update?
If it's the driver, will the http://ark.intel.com/compare/85254,87740 Braswell NUCs also get the same driver support?
It seems the images were already posted on the first page, sorry.
I was under the impression that there would maybe be improved drivers coming along with the Skylake NUCs.
The newest NUC models with 6th gen processors "Skylake" support HD passthrough. They come with Intel® HD Graphics 540 (i5 processor) and with Intel® HD Graphics 520 (i3 processor).
But what does this mean for Braswell NUCs Intel driver support? Is it due to Windows drivers or hardware?
Is the only solution to purchase Broadwell or Skylake NUCs?
It's not hardware related... it is a Windows driver related issue. The Braswell Celeron/Pentium can do HD Audio pass through under Linux.
The Intel J1900/J2900 when first released couldn't do HD Audio pass through but the Windows driver was released to enable the feature
It's already known that it's not hardware related as Linux supports DTS-HD and Dolby TrueHD audio in both NUC5CPYH and NUC5PPYH.
The thing is that Intel is not releasing a proper driver to support it in Windows.
Why doesn't Intel wants to make a decent driver. It indeed is known that DTS-HD is supported in Linux, so it's absolutely not a hardware issue. But somehow Intel doesn't want to make a decent windows driver for it :-(
I've now decided to buy a AMD Athlon 5350 (which is way less powerful). But when proper driver are released I might reconsider the n3700 while I think it's a very decent processor with very good power usage.
You need to first install Openelec on your NUC from here
http://openelec.tv/get-openelec OpenELEC Mediacenter - Download
Once installed, and your NUC is connected to your AV Receiver (that can do HD Audio) you then go to Settings, System, Audio Output and there should be an option to Enable passthrough, turn that on, then play a movie that you know has HD Audio and you should see the HD-Audio type highlighted on your AV Receiver...
http://kodi.wiki/view/Audio_settings Audio settings - Kodi
Thank you theaccent and GumboJohn, I was able to get OpenElec up and running and I see that TrueHD and DTSHD are listed as options, however where my office is, I can not actually test that they work with speakers, have you guys actually tested it and everything works fine (the kodi options say it's a receiver supported option, but does the NUC actually output the audio.)? Also, if it does work, how would one tell if it was DTS HD/True HD, vs the non-HD version?
Thanks for all the help, I will see what I can do about getting engineering to look at it as well.
If you follow the link to the kodi forum, I describe in detail what I tested using OpenELEC and which version I used. MPEG2 was accelerated, but deinterlacing was putting a heavy work load on the CPU as I recall. When I got it all working with Mythbuntu and Kodi on top, I had to update the Kernel to a version 4 kernel and install the latest VAAPI stuff. That was a couple of months ago so I don't remember exactly what I had to do to get everything working, but I think I had to apply an update to pulseaudio to get 7.1 output. OpenELEC "just worked" out of the box.
Yes I can confirm that on my NUC5PPYH using Openelec connected to an Onkyo AV Receiver that the display on the receiver will display DTS-HD/True HD. Under Windows, playing the same file will not display DTS-HD/True HD on the AV Receiver display, and there is a definite difference in the sound that gets produced. Let me know if you need some more details photos, videos etc...
I previously owned the N2820, now the N3150. I strongly engaged in trying to resolve this on the N2820, and intend to do so with this one, too.
The situation was the same with the N2820 (And this was a year, year and a half ago), although that one actually claimed support, printed "on the box" (Thus they had to open up for returns on grounds of false advertising, although very "low key"). No problems with HD audio passthrough over HDMI with linux (OpenELEC is a prime example for demonstration), but no driver support for this under Windows. While we did the whole IME / Trusted Execution dance back then too, with the N2820 - Intel accidentally and unintentionally "spilled the beans" on selective driver support being the case. How? The GFX drivers for the D34010WYK, "accidentally" worked on the DN28xx models. Installing these drivers enabled DTS-HD / MA and Dolby TrueHD passthrough. I tested and confirmed this working myself (and many, many others), on the DN2820FYKH. Still, knowing this, they decided not to patch this into the official drivers for the N2820 (Although they did do so, for the J1900). As the SoC has changed too much with the Braswell, this GFX driver mentioned does not provide a workaround in this case. So there you go; Its not a matter of the hardware not supporting it (as any linux / OpenELEC user, or installer of the "wrong" drivers for the N2820 will demonstrate for you) - but a selective choice in support.
For reference - see the original post regarding this, here at the Intel Community (linked to most relevant post # ).
And, for tidyness - the post where this was fixed for the J1900:
A few notes on the original fix to support HBR under linux (associated links can be found there) - this was done already back in 2012, by one of Intels own devs (Wang Xingchau). This patch was included in kernel from 3.10.xx, already in July 2013.
http://kodi.wiki/view/Intel_Linux_Modifications_for_HD_Audio Intel Linux Modifications for HD Audio - Kodi
With this in hand, and you currently looking further into the OpenELEC / Kodi (formerly named XBMC) support for HD bitstream passthrough (and thus observing the hardware capacity first hand), hopefully we can convince whom ever is on the fence about this, to change their mind. I am in no way officially associated with the developers of the open source software Kodi or OpenELEC, but if assistance is needed - I am sure we can establish contact between you or the driver engineers, and the devs of Kodi and OpenELEC. Although, reviewing the above history on this subject - I strongly suspect the Intel driver techs already know all they need, to make this work if they so choose.
To clear up a few small notes. In regards to HD audio (bitstream) passthrough - Indeed Kodi will say its a reciever supported option. HD audio passthrough (also known as bitstreaming) sends the untouched (still coded and/or compressed) HD audio stream through the secure HDCP channel of HDMI, on to the AV reciever unit - leaving the licenced hardware of the AV reciever to do the decoding of these HD audio formats. This means that the AV reciever needs to support decoding of these formats. Hence the "Reciever supported option" note.
Once the reciever receives a bitstream (e.g. HD passthrough over HDMI) from the source (The NUC in this case), and given that the connected reciever supports the audio format of course, the vast majority of recievers will clearly indicate what audio format it is recieving on its display - either through text or an icon/logo symbol. Some reciever units may only display or text-scroll this information, for a short while right after the sound stream input starts, and when there is a change in audio format input. Others will indicate what type of signal it is recieving, as long as the (audio) stream plays. Most modern AV recievers have a remote button or On-screen menu item, which will show technical details for the input it is currently receiving.
A note on DTS audio: The common HD audio format of DTS, is DTS-HD / DTS-HD:MA / DTS-HD: Master Audio (displayed as different names in different contexts, all the same content). If you conduct a test with a video containing a DTS-HD soundtrack, make sure the receiver indicates more than just "DTS" / "DTS Audio". "Baked inside" the full DTS-HD audio track, is a simpler, low bitrate "DTS core". This is the older, non-HD DTS audio format, which is included in the audio stream as a fallback to provide some form of backwards compatibility with older, non-HD supporting audio equipment. This type of "baked-in legacy stream" is not available with Dolby TrueHD.
Hey guys, thank you all for the explanations. I was able to get engineering to look at it. I can't promise a solution, but will certainly let you know if we get one. Thanks for all the help!
We are glad to hear this. Now that it is known that Intel Celeron SoCs with HD Audio has had the functional hardware capacity of HD audio passthrough (including HBR), ever since Sandy Bridge (proven and enabled on Linux by Wang Xingchau from Intel) - we can only be patient and hope that the engineers will patch the Windows drivers like they have done before. At the very least, for the current platforms within service life.
We most surely hope to hear good news, and thank you for your precious help so far.
As things go, I won't be that optimistic for getting the support!
I'm getting frustrated every day with Intel's support.
Started with this DTS-HD and Dolby TrueHD not being supported under windows (INTEL YOU SHOULD HAVE STATED THAT ON THE BOX / SPECS!!!)
Then continued with drops while transferring files via USB 3.0 using my NUC5PPYH ( ).
I truly regret buying this unit. I should have built a mini ITX PC.
We understand you are interested to have DTS-HD, Dolby TrueHD Audio on the Formerly Pinnacle Canyon NUCs with Windows®; however, the hardware is not prepared to support it. Windows® provides with the supported resolutions of the hardware only while Linux provides with additional resolutions using software tools.
mikec_intel and cvare - Are you both Intel employees?
mikec_intel - At the very least we are keen to get HD Audio passthrough working on these NUCs, your statement of "Linux provides with additional resolutions using software tools." this is what a Windows software driver is, is it not? On previous NUC models it was stated on these forums that HD Audio wouldn't work and then either by accident or with a bit of effort they support HD Audio pass through...
cvare, thanks for your positive response... keep us updated...
Can you explain exactly what you mean by that, mikec_intel? As I understand it, pass through is simply putting the unaltered digital audio stream down the HDMI connection. There is no processing by the hardware or software, it just goes straight on through to the end device to be decoded. How is it that Linux is using these "software tools" to do something that is apparently impossible for Intel software (video drivers) to do? It's not like Linux is faking the stream, it is simply passing it through.
There must be some unspoken reason that Intel is not wanting to pass the unaltered stream through the HDMI connector and on to the AVR device for decoding. Is it because of some kind of DRM issue? I think everyone deserves a straight answer on this subject instead of what I've been reading in this thread. Is Linux in violation of some kind of DRM legal requirement when it allows this to take place? It is obvious that the hardware is fully capable of simply passing through the unaltered digital stream, but is allowing Windows driver software to refuse to do so. So why can't we all just put our cards on the table and be honest about this? I don't think bluffing along with semantic word games is doing anyone any good here. Personally, it's really turning me off to using Intel boards for projects. It's artificial limits like this that turned me away from Window towards Linux.