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.
I still refer to the drivers for the N2820 "slip". You gave us the same go-around back then, "Windows HD audio passthrough utilize hardware enabled PAP and the Celeron NuCs just don't have that support" [paraphrasing]. And all it took to enable HD Audio (HBR) bitstream passthrough under Windows, was applying the D34010WYK drivers (presuming Trusted Execution Engine drivers were already installed). Everyone here already know this can be solved by patching the Windows drivers. Just a shame these drivers don't work with the later generation HD Graphics, and thus the Display Audio.
There is no "magical software solution that only works on Linux" - no more than is the case in the prime example above. On linux, it was a matter of patching the original Intel drivers, that were messing with the packet-, thus the channel order for non-PCM compressed (DTS-HD/TrueHD) streams. These are different to uncompressed multichannel PCM streams! Non-PCM compressed streams must -NOT- be channel mapped, but sent "straight through"!. In regards to Windows requirements - the Trusted Execution Engine is there (and working) to satisfy the Windows needs.
Intel HD Audio hardware supports HBR (has done a very long time): http://crashrecovery.org/hdaudio_pdf/HDA035.pdf http://crashrecovery.org/hdaudio_pdf/HDA035.pdf
And please note, to once and for all make sure we're on the same page here: No one here is suggesting Intel enable these units to DECODE HD audio HBR formats. Thats the domain of appropriately licenced equipment. What we're asking here, is that Intel enable HD audio (HBR) bitstream passthrough over HDMI - so that we may pass that bitstream to our external, licenced equipment (AVR).
I don't know why are you suggesting us that this driver BUG is hardware "feature". As we can see in other threads there were issues with other NUCs like i5 or 2820 but new drivers solved problem.
Everybody knows that hardware IS capable to PASSTHROUGH but it seems that you are trying to downgrade functionality _on purpose_. Would you care to give us real reason why? Stop treat us like idiots or something please.
This online community is quite disappointing. Customers come here and voice real product defects. I have seen multiple former Intel employees who try to help the best they can here, but then there are the current employees(I'd wager offshored), who seem to do little more than kick the can down the road by mostly posting useless links and needlessly asking customers to do things like BIOS upgrades when release notes indicate no fix for anything remotely close to the customer complaint.
Why do we have to go through this again? We have been through this with the n2820 that was eventually fixed. These nucs primarily are designed to run as htpcs not as a desktops, and most of them are hooked to expensive home theater systems to enjoy the best sound .
We truly appreciate your input here, and willingness to engage in the issue as far as your capacity goes - and passing it on to those who can look into the elements beyond your capacity. We will be waiting for (hopefully good) news, and thank you for your time and work so far. Truly, it means a lot to users of Intels hardware (and I believe and hope that shows in this and other related threads).
Now guys and gals, I guess we are just going to have to wait to see what comes back down the pipeline from the (driver) engineers. Cvare has done what he/she can for us, for now - and I am sure cvare will let us know as soon as there is something new to tell. If the engineers are looking into it, there's really nothing more to do but wait (?) For now,
The N3000, N3050, N3150 and N3700 share the same Graphics (and Display Audio) driver. The GPUs are pretty much the same, except the number of execution units and burst frequency. This should not affect the Display Audio part, though.
Dear Intel Team,
what you are doing here with your customers is a joke.
How can it be that a company like intel isn´t able to fix a driver for such a long time?
In an open source community problems like this are mostly fixed within 24 hrs.
Meanwhile i have to ask myself...
Can´t you help us or don´t you want to?
It´s a shame whats going on here....
I'm a bit late to the party, but I second everyone's comments here.. It totally defeats the purpose of using this(Intel NUC5PPYH) as an HTPC if we can't passthrough/bitstream the HD soundtracks!! (DTS-HD, Dolby TrueHD etc) I have also purchased the NUC5PPYH, and was disgusted to find that it does not passthrough the HD soundtracks. I'm also running Win 8.1 Pro x64, with ALL the latest drivers from Intel and the latest BIOS (0047). And yes, I have a compatible hdmi cable and a compatible AV Receiver...
@Intel - "Intel® High Definition (Intel®HD) Audio via the HDMI v1.4b interface through the processor" is enough to lead most people to believe that the functionality of passing through/bitstreaming of the HD soundtracks should be possible on a unit that is brand new and up to date with the modern technologies of today.. or so we were lead to believe..
Come on Intel, get this resolved! We KNOW the hardware is capable!