Community
cancel
Showing results for 
Search instead for 
Did you mean: 
DTutt
Novice
4,027 Views

Nuc6cayh not supporting hd audio 192/24

Just got this barebones Nuc and put a 120gb ssd and 8gb of ram in. I'm running Windows 10. I am using it as a music player with an ethernet connection to my pc in another room with all my music files. I have it connected to my Marantz 1608 via hdmi. I use JRiver Media Center to play my music from my server through the Nuc to the Marantz receiver.

I don't know which is responsible for the issue (The Nuc hardware, Windows, or JRiver). Here's the issue.

I tried to play a flac file at 192/24 hd audio in JRiver. In JRiver, I've chosen to play through my Marantz using Wasapi direct connection. When playing I see it downsampled to 192/16 with a message that there aren't enough bits for the selected output (it recognizes that it is coming in at 192/24). I know the Marantz can handle 19/24 - it has done so via hdmi and ethernet to my Oppo 103 blue ray player without any problems.

Here's the other odd thing - I ordered this same model Nuc preloaded with the JRiver software and running Linux from the JRiver people. I am returning it because I just don't understand Linux and want a Windows environment. While I had it I played my 192/24 files through ALSA to the Marantz with no issues whatsoever (it even padded the bit depth to 32).

So I'm wondering where the problem is. I think I have all the latest drivers for everything (I just updated the graphics driver to the newest Intel HD graphic driver for the 500 model on my Nuc).

In windows it says the Marantz is selected and supports all samples up to 192 and bit depths of 16 and 24. However, I don't see a way to select any of these. While searching around the net I kept seeing this same screen but with checkboxes by the sample rates and bit depths for the user to choose - I have no such options. They are just listed as "supported".

I don't know what else to check.

Is this a Nuc/Intel hardware issue or a Windows 10 issue?

Any help would be greatly appreciated.

Thanks

23 Replies
idata
Community Manager
300 Views

Thank you very much for contacting the Intel® Communities Team, zonk.

 

 

Allow me to share with you that the 192/24 format is not supported by this NUC.

 

 

 

Antony S.
DTutt
Novice
300 Views

Are you sure it isn't supported? I had this exact same model Nuc ordered from Jriver that was running Linux. I had no problems running 192/24 using the direct connection with ALSA. In fact, it was padding everything to 192/32. I returned it to Jriver because I'm not comfortable with Linux.

While running Windows 10 on my new Nuc (though the same 6cay model as the one I returned), I can't even get a clean 24 bits on 96/24. Jriver software says it is playing back at 192/16 because there aren't enough bits. It sounds more like an operating system thing. I can get 96/24 padded, which implies, I think, that it can't get a clean 24 bits even on 96 or 88.2 khz.

Are you saying t he Nuc isn't capable of 24 bits at all, because I'm pretty sure I got that, and more in Linux?

When I go into Sound properties in Windows it shows my default Marantz receiver and it says it supports 16 and 24 bits and all the way through 192khz - but there are no check boxes for any of the combinations for me to try (I can't even select cd sound, 44.1/16). It just says it is supported.

Thanks for any additional help/insight you can give.

idata
Community Manager
300 Views

Thank you very much for your prompt reply, zonk.

 

 

The 192/24 format will not be supported by this model of NUC. In the following link, you will find the Technical Product Specifications for this specific NUC. On page 3, "Specification Changes or Clarifications" section, on September 2017 this feature was removed from this document since it is not supported by the NUC: https://www.intel.com/content/dam/support/us/en/documents/mini-pcs/nuc-kits/NUC6CAYS_NUC6CAYH_TechPr... https://www.intel.com/content/dam/support/us/en/documents/mini-pcs/nuc-kits/NUC6CAYS_NUC6CAYH_TechPr...

 

 

Please bear in mind as well that Windows® 10 is the only https://www.intel.com/content/www/us/en/support/articles/000005628/mini-pcs.html Operating System Supported by your unit.

 

 

 

Antony S.
DTutt
Novice
300 Views

So this is frustrating. I just had this same model Nuc running Linux which supported 192/24 and 96/24 using ALSA.

Is it possible that an older version of this model with a different type board supported these formats?

Also, after reading that document you attached, does this mean this Nuc doesn't even support 96/24?

Is so, do you gave any Nuc kits that do support 192/24 via hdmi (or toslink)?

Thanks

idata
Community Manager
300 Views

Thank you very much for your reply, zonk.

 

 

Indeed, as per the https://www.intel.com/content/dam/support/us/en/documents/mini-pcs/nuc-kits/NUC6CAYS_NUC6CAYH_TechPr... Technical Product Specifications of the NUC, the 96/24 format is not supported as well. You can double check our NUCs specifications by clicking https://ark.intel.com/# @PanelLabel70407 here, you can double check the sound format on the datasheet of it and you can select the one that better accommodates for you.

 

 

 

Antony S.
AMorr4
Novice
300 Views

You guys @ intel (all of you: developers + support) should be ashamed!

You SELL something as capable of supporting PCM bitstreams of 24bit@192kHz, and then repeatedly downgrade the specs, and now come and tell us that such devices aren't capable not even of 24bit@96kHz.

This is absolute *b.s.*.

Such devices ARE indeed capable of such PCM bitrates on Windows 10!

It's your latest device drivers that have removed such capabilities.

For reasons unknown, rather than provide improvements, your "device drivers updates" remove capabilities...

So, in case you are not informed, please note that any such NUC can sustain bitstreams of 24bit@192kHz (under Windows 10 as well) by just installing an OLD version of your own "Intel Audio Driver", as I detailed /message/503256# 503256 here.

And as I clarified in the same thread, even the very basic and general purpose "High Definition Audio Device" driver supplied by Microsoft with each and every WINDOWS installation does provide support for PCM 24bit@196kHz and, obviously, this also works just fine on your "Intel NUCs" as on any other system.

So please, rather than telling people what your *downgraded specs* now say, at least point them to an existing and effective workaround/solution for such a LIMITATION that is imposed by your own "Intel Audio Driver", not by Windows, nor by the hardware itself.

I repeat: on such NUCs 24bit@192kHz PCM works perfectly (even under Windows 10!) when using the old version 6.16 of your own "Intel Audio Driver", or even the basic/generic "High Definition Audio Device" driver provided by MS.

It's about time someone @Intel understands that nowadays 24bit audio is not an esoteric option, but rather the de-facto audio standard (nobody cares about 16bit audio anymore!). You SHOULD provide support for 24bit@192kHz OUT OF THE BOX (as it was promised in the original specs!), without people having to waste time looking for workarounds (while even being mislead by Intel on this very same forum), then searching and installing old Intel drivers, and getting mad again once your most recent (and meaningless) Intel driver update gets automatically installed.

And you know why you should really take care of this?

Because support for 8 channels of 24bit@192kHz PCM was part of the original HDMI 1.0 specification...!

Guess what year was that?

2002!

And you guys still come and tell us that such bitrates cannot be achieved (FALSE!), quoting your latest *downgraded* specs?

Seriously?

MCont7
Beginner
300 Views

Hi All:

I experienced the same issue 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.

I discovered a couple of things:

If you start playing HBR audio and then turn off the screen, 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 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.

Go figure.....

AMorr4
Novice
300 Views

Hi Zonk,

I'm not surprised you didn't really get any help/solution from Intel: they're too busy downgrading their specs, rather than fixing issues or suggesting workarounds for what their specs originally promised and never delivered.

The problem in your case is that having the "latest" Intel driver installed won't help, at least as far as the "Intel Display Audio" driver is involved.

You can stream 24bit@192kHz PCM via HDMI by installing the 6.16 version of that driver (or even the generic "Microsoft High Definition Audio" driver provided with Windows) instead of the latest version.

Please note: you can still have the latest HD Graphics package installed, but the "display audio" component should be replaced with good old version 6.16 (or the generic MS equivalent) for any meaningful 24bit PCM to work...

You can find some hints /message/503256# 503256 here.

Hope this helps.

DTutt
Novice
300 Views

Thanks for reaching out. This won't surprise you at all, but after having success with your thread (rolling back to an old driver) - I was able to get all my sample rates through hdmi. Since then, I bought a new preamp that doesn't have hdmi so I was back at square one with an optical missing 88.2 as an option. Well I thought I'd check old drivers the same way for the high def audio device - lo and behold, I found a driver from 2015 that allowed all the sample rates the "new" driver can't handle. Working beautifully! It should, obviously, never come to this but thank goodness for the internet and individuals willing turn every stone looking for a solution - and finding one where Intel chooses not to....emphasis on "chooses".

Still boggles the mind that they chose to roll back performance that is on that device.

Now my only problem is trying to find a similar fix for usb audio - it is the same issue - the generic driver is missing support for 88.2. Any ideas?

Anyway, thanks for checking in and please let's keep on them and make sure the support their products the right way.

AMorr4
Novice
300 Views

Hi Zonk,

I'm glad to hear that rolling back to the old driver solved the issue, and allowed you to stream PCM @ 24bit*192kHz.

And I'm also glad to hear that, following a similar approach, you were able to solve the issue with the optical connection.

I was aware of your other thread ("/thread/124486 NUC6CAYS high definition audio problem") and I actually had the feeling that you may have resorted to buying such a preamp to bypass the HDMI pass-through problem. That's the reason why I was so harsh in my rant against Intel above: they should have told you from the very beginning how you could achieve such bitrates via HDMI by rolling back the old driver (or using the generic MS equivalent). They could have warned you that such a workaround was not officially supported, or whatever else; yet they should have provided such a clue from the very beginning, and that's one month ago!

Instead they didn't provide any hint, and just told you that, whatever the original specs of such NUC promised, those specs had been repeatedly revised, and according to their latest revision it's absolutely normal and acceptable that in 2018 such a piece of equipment (with HDMI 2.0) is NOT even capable of supporting a PCM bitstream @ 24bit*96kHz. Isn't it ridiculous?

As for the USB/HD Audio issue, I'll leave it to Intel to provide whatever official feedback they have (if any) in the related thread, and I'll take advantage of this conversion here just to give you a few hints and ideas (I have a different NUC, and I don't have an external DAC/Preamplifier connected via USB: so I'm not sure that any of the following will actually help you).

First of all, my assumption (judging from the specs+photographs of the back panel) is that your DAC/Preamp has a very basic USB 2.0 input: as far as I'm aware of, all such equipment doesn't really need anything more than that to support HD audio bitstrams (24bit*192kHz stereo equates to a bitrate of just 9,216 kbps that is comfortably within the capabilities of USB 2.0).

On the other hand, if I'm correct, your NUC only expose USB 3.0 ports... but please note that, according to spec, it should also have a couple of internal headers for USB 2.0 directly on the board.

So, if this is actually the scenario you are dealing with, you currently have a normal USB2 cable connecting one of the USB3 ports on your NUC to the USB2 input on your DAC/Preamp. And of course your NUC USB3 ports are probably driven by an Intel specific driver...

Hence, one thing you may want to try is to select such driver in "Device Manager", choose "Update Driver", then "Browse my computer for driver software" and finally "Let me pick from a list of available drivers on my computer"...

 

If you happen to find any other suitable driver there (not from Intel) you may want to give it a try.

 

It's possible that if there's a generic MS/Windows driver this may easily solve the issue (it may not take advantage of the specific architecture, and thus put slightly more load on the CPU, but if it solves the problem, why not?).

The other thing you may want to try is to use the very basic USB2 connections available on the board and see if they'll do the job: you can locate such USB2 headers at pag.15 of the https://www.intel.com/content/dam/support/us/en/documents/mini-pcs/nuc-kits/NUC6CAYS_NUC6CAYH_TechPr... TPS.

Being older technology, hopefully Intel has stopped messing around with their drivers long time ago, well before they entered their current approach of cutting features (and specs) whenever something doesn't appear to work as expected... Plus, you will get a very basic, simple and consolidated USB2 to USB2 connection (so there's less chance the Intel driver is messed up to cope with backward compatibility issues, as their USB3 driver probably is, having to provide both USB3 capabilities and USB2+1 compability/support...).

Please note that according to the description at pag.22 regarding those USB2 headers "one port is reserved for an M.2 2230 Module"... whatever that means, and however it applies to your case, you should still have at least ONE USB2 header available.

So just get your hands on something like https://www.amazon.com/StarTech-Motherboard-4-Pin-Header-USBMBADAPT/dp/B000IV6S9S/ref=sr_1_12?ie=UTF... this for just a few bucks: at first glance, it seems to fit the USB2 header description provided at pag.42 of the Intel specs (please verify yourself).

Plug it in, connect a USB cable to your Preamp/DAC and see if a basic connection via good old USB2 solves the problem.

Once again, you probably have a double chance of getting this to work: using the specific driver provided by Intel, or the generic MS/Windows driver. The latter drivers are widely tested and are supposed to work with a lot of different systems and architectures: so while they may not be very efficient, they really should be pretty reliable.

If one way or the other such a basic USB2 to USB2 connection does work, as I assume you don't want to drill or mess around your NUC case, you may want to check http://www.gorite.com/intel-nuc-products/intel-nuc-replaceable-lids here: I didn't look carefully, but I assume they have a suitable "lid" for your NUC to expose the USB2 ports in an elegant way (and as they write at the top of the page, just contact those guy if you don't find - or you are unsure - of what you actually need).

Of course, if you think that exposing such additional USB2 ports may be a "plus" anyway, you can skip the preliminary test with a simple (and cheaper) header-cable, and just purchase directly an appropriate USB2 "lid" that has surely been tested to be compliant with your NUC.

 

I really hope some of the above helps.

And of course, if it does, please let everybody know: I guess there may be people with other USB DACs having exactly the same kind of problems you reported...

MCont7
Beginner
300 Views

S

Hi All:

I experienced the same issue 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.

I discovered a couple of things:

If you start playing HBR audio and then turn off the screen, 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 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.

Go figure.....

MCont7
Beginner
300 Views

Hi All:

I experienced the same issue 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.

I discovered a couple of things:

If you start playing HBR audio and then turn off the screen, 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 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.

Go figure.....

n_scott_pearson
Super User Retired Employee
300 Views

I would add that this limitation is not limited to the NUC6CAYH (pun not intended). It appears to be a universal limitation in the Intel HD Audio driver. Since previous versions of this driver were found to support 192/24, it has to be a driver-imposed limitation. I would sure love to see the Intel engineers explain why this limitation is being imposed.

...S

AMorr4
Novice
300 Views

Scott...

as I documented in a bunch of other threads (and as you may already be well aware of) this issue has been affecting just about all NUCs starting with the Skylake generation.

All of them were described in their original TPS as being capable of 24bit@192kHz (x 8channels), and all of them had their specifications downgraded afterwards (usually after a year or so...).

And it's not just NUCs: whatever hardware uses recent generation of Intel processors and embedded HD graphic subsystem (and thus the same driver packages) intended for the so-called "Mobile segment" has been suffering of such a limitation (laptops, tablets and whatever else).

Even worse... even after Intel had been informed of the problem, they simply (and very slowly) updated the specifications for each and every product or board affected, without ever fixing the original specs of the processors involved. So, for instance, if you search for the specs of the i5-7260U processor (which powers the NUC7i5BNK, but also a lot of other hardware) you'll end up reaching this rather generic (yet extremely detailed) document:

https://www.intel.com/content/www/us/en/processors/core/7th-gen-core-family-desktop-s-processor-line... Datasheet, Vol. 1: 7th Gen Intel® Processor Family for S Platforms

Check page 42 and you will find the descriptions of the audio capabilities including the infamous "LPCM 192 kHz / 24bit, 8 channel" which is said to be supported both via HDMI and DisplayPort.

And guess what, in the related specification update, which you can reach through this page (https://www.intel.com/content/www/us/en/processors/core/core-technical-resources.html Intel® Core™ Processors Technical Resources), there's no mention of any correction to the above (it still waits to be corrected!).

Which explains why a whole bunch of products by a whole bunch of manufacturers (including INTEL, of course) were released with such a spec, that the Intel driver didn't actually support.

But what makes the whole matter even more EMBARASSING is that if you open the Device Manager, select the infamous "Intel Display Audio" component, then right click to UPDATE, then "browse my computer for driver software", then "let me pick from a list of available drivers on my computer" you'll find out that, of course, there is an alternative to the Intel Display Audio driver...

The generic "High Definition Audio Device" driver provided by Microsoft!

And of course the generic and HW independent Microsoft driver supports 192kHz/24 bit PCM audio PERFECTLY (as old versions of the Intel own "Display Audio" driver also do)!

It's not surprising after all: the requirement for 8 channels of 24bit/192kHz PCM audio is as old as the very first HDMI specification, released in December 2002.

Which makes the whole Intel behavior surrounding this issue (and all the confusion it has created and it still creates to end users, OEMs and even to the Intel own support) simply unforgivable.

These threads are particularly eloquent (but I could point you to many more, starting with the my own in /thread/115625 June 2017):

(pretty recent - and, more important, "assumed answered"... how embarrassing is that? the guy replying had no idea whatsoever of an issue that end users know perfectly well... and of course, it's no surprising at all that the guy who opened that thread with such a specific question didn't follow up providing useless details about his system... why take the pain to tell again the whole story to someone at Intel that doesn't have the faintest idea of their own screw-up? and btw: I still cannot believe that people @Intel don't understand how bad all this is for their reputation..)

(not so recent, but the interaction in this thread is indeed VERY interesting: "your Dell laptop does support 192/24 PCM because the specs of our processor say so!!!"... LOL)

The last one is pretty recent and absolutely indicative: it took the support staff nearly two weeks of completely useless interaction with "the customer" (who in this case even took the pain to provide all details!) before someone @ Intel understood that the issue is very well known and that Intel has long decided not to address it…!

Yet, all in all, no explanation is given to that customer (who clearly already knew the whole story!) about the simple and eloquent question he posted as the subject of his topic:

"Why no Audio 24bit/192khz possible with newer Graphicdriver-Packages"?

Which is exactly the same kind of question you posted in your comment above.

Well, I'm afraid that the reason why an answer to such an obvious question has never been given is very simple: they just don't care.

I really cannot find any other way to explain why - after nearly two years - Intel has not provided a single valid reason to clarify why such an issue should remain unfixed and unaddressed.

n_scott_pearson
Super User Retired Employee
300 Views

I resent the implication; it patently isn't true. The folks at Intel *do* care. Their support is far better than the vast bulk of the industry (unfortunately, that's not saying much). I worked at Intel for 21 years. Even in retirement, I still care enough to come here and spend part of my day sharing my expertise and helping folks with their issues.

I am well aware of what has happened here and, as a long-time employee of Intel, likely know exactly why this occurred. Regardless, here we are. Support for a capability got dropped. Yea, the hardware can support this capability - but this means nothing if the software (driver) no longer can. Let's stay optimistic; maybe someday soon the capability will be restored...

...S

AlHill
Super User
300 Views

GuineaPig, I tried reading this thread, but I have already read "War and Peace". Long-winded and no real substance.

You will not find a nicer group of folks than those at Intel. You should be thankful that your nonsense is even responded to.

Doc

AMorr4
Novice
300 Views

Scott,

I understand your feelings given your history @Intel, but the simple FACT that after nearly 3 years no reason has been given for all this, and that in the meantime Intel kept releasing devices (and processors) with specs that the Intel Display Audio driver never actually supported, tells the whole story ANYWAY. It's simply self-evident.

I'm sorry you I hurted your feelings: I didn't know you were ex-Intel, and I posted such a rant just because you were the N-th guy in this forum to ask "why this limitation is being imposed", and receiving no answer.

And there cannot be an answer because every resolution, refresh rate, etc. works absolutely fine with 24bit/192kHz PCM when using the Microsoft generic "High Definition Audio Driver" (or the old 6.16 Intel Display Audio driver).

Given you are technically inclined...

It's the receiver/amp at the other end of the cable that does the decoding, splits bytes among multiple channels, and finally performs digital-to-analog conversion of whatever it receives.

The Display Audio driver doesn't do any processing: all it has to do is to PASS-THRU whatever audio bitstream (be it DTS, or Dolby or PCM) through the port, interleaving it with the video signal. That's it.

If the Microsoft driver does that (and old versions of the Intel driver also did) it's pretty hard to accept that the latest Intel drivers cannot.

And please note that this is really annoying, because whatever non-default audio driver you configure to bypass this limitation, sooner or later you will end up with the latest Intel driver being installed again, your system downgraded, and you'll need to reconfigure everything.

The trick of telling Windows not to include "new drivers" with Updates (Advanced System Settings > Hardware > Device Installation Settings) doesn't seem to be effective anymore, or, at least, NOT for the Intel HD Graphic Package (maybe because it's downloaded and installed as a monolithic EXE?).

So you have to resort to use Group Policies to block drivers from being updated...

End users shouldn't have to go through such stuff to configure their system and play some HD music they have bought on HDTracks (or a Blu-Ray with 192/24 PCM audio).

Furthermore, preventing driver updates means that no other driver will ever be updated... not very nice, huh?

 

And it also means that you may have to mess around again with driver installation settings (to resume driver updates) whenever you attach a USB device that your NUC has never met before...

And, of course, when you do, you'll end up also getting the downgraded/limited Intel Audio driver installed once again.

Does this sound reasonable at all?

Finally, if this was not enough, please note that whenever (by accident or because you really need to install/update another driver) the Intel Display Audio driver ends up being installed again (and the system downgraded), you will also need to reconfigure all your software, because the WASAPI output definition of each program is directly tied to the specific driver being used. So, if the driver changes, the previous WASAPI configuration is LOST, and all multimedia programs that were configured to use WASAPI will automatically switch to DirectSound instead (which means getting unwanted "windows sounds" while listening to music and so on).

So, all in all, you will have to:

 

- uninstall the latest Intel Driver;

 

- install the old one (going through a very specific sequence of steps, which is not very intuitive for most users: you have to reach the infamous dialog box with the "Have Disk" button, and then ignore the subsequent Windows warning saying that the driver may be unsafe...);

 

- open each of your multimedia programs (Kodi, FooBar, etc.)

 

- reset the "Audio Output" configuration of each program to use WASAPI with the newly (re)-installed "old" or "generic" driver, rather then DirectSound.

Believe it or not, whenever I have to waste my time going through such steps again, it's pretty hard for me to think nicely of Intel.

Do you think that I'm the only one?

Ask yourself why users who are well aware of this situation, from time to time, come here on this forum and explicitly ask if this problem has been solved.

And most of the time the Intel representative replying doesn't even know the issue, and starts inquiring about the "user configuration".

I'd be curious to know your feelings about a thread like this and its being "assumed answered" (but of course, no need to reply; you've said it all already: everything is OK).

 

http://communities.intel.com/message/519487# 519487 http://communities.intel.com/message/519487# 519487

http://communities.intel.com/message/519487# 519487 http://communities.intel.com/message/519487# 519487

And when an appropriate reply is given from the very beginning, as it happened in this specific thread, I cannot help asking myself: why nobody tells the poor guy that, if this capability is really important to him, he can simply use the generic Microsoft driver or an old Intel driver instead?

But surely the problem is me, and my extremely unusual and very awkward concept of "customer care".

Kindest regards,

 

Agostino
AMorr4
Novice
300 Views

Dear Al Hill,

indeed we have different opinions of "War & Peace" and even a different concept of the meaning of "nonsense".

Leaving Tolstoy aside, to me "nonsense" means:

  1. releasing a generation of NUCs (SkyLake) as capable of supporting PCM @ 192kHz/24bit, while the Intel driver doesn't support that;
  2. this, of course, also implies a different concept of "TESTING" (it's clear that no test whatsoever was ever performed to verify that such capability was actually supported);
  3. spending months (nearly 9) telling customers who complain about this issue to check their HDMI cable, to buy better ones, of even try with a different amp/receiver...
  4. then, all of a sudden (and without any sticky announcement on this forum, nor any apology) downgrading the specs of all such NUCs to 192/16 (which doesn't really tell what support is available for 24 bit audio);
  5. in the meantime a new generation of NUCs gets released as being capable of PCM @ 192kHz/24bit, which the driver still doesn't support;
  6. GOTO 2.

As the algorithm is iterative (which is also "nonsense"), fortunately for me there's no need to fill tons of pages as Tolstoy did.

 

And please note that the above also applies to any PC, laptop, or whatever (by any brand) that happens to rely on the same "processor + graphic subsystem" of such NUCs.

Last but not least, to me "nonsense" is also the fact that if you simply switch to the generic Microsoft driver (or manage to find an old enough version of the Intel driver) 192/24 works perfectly!

 

Yet, you have to fight and mess around with your own PC quite a bit to keep such a non-default configuration alive, and prevent the latest (limited) Intel driver getting reinstalled every other day...!

 

Which, at least for me, is also "nonsense".

Of course there's no need to reply.

I got your point: for you all the above is NORMAL; hence - for you - it is "nonsense" that I write about it.

Cool...!

MLevi
Valued Contributor I
300 Views

GuineaPig,

You have been documenting this for at least a year and you're still writing about it. For what purpose?

(e.g., http://intel976.rssing.com/chan-11514708/all_p511.html Intel Communities : Discussion List - Intel® NUC ).

You have a solution, but you still want to sow seeds of discontent. Go find your smiley face and stop grandstanding on an issue where there is a solution that works.

It may not be an Intel solution, and if you don't like Intel products, vote with your wallet.

n_scott_pearson
Super User Retired Employee
58 Views

Thank you Mike. An appropriate response indeed.

...S

Reply