Confused about XBMC support for HD audio format vs OS support (Vista w/nVidia)
#1
Question 
I'm confused, and would appreciate someone clearing this up for me. I run Frodo 12.2 on Vista 32bit, using a Nvdia GT620 to an Onkyo 509 AVR. Following the guides here, if I look at the properties of this connection as the playback device, the only supported formats I see for the Nvidia High Definition Audio are Dolby Digital (even tho both the video card and AVR support DTA-MS, TrueHD, etc). "DTS" and "Microsoft WMA Pro Audio" are listed, but don't work; Windows says it was unable to play the test tone, and so these 2 are unchecked.

I tried an EDID overide, created by MonInfo - no other formats show. I have the latest drivers (320.49, updated today). I also don't see a max number of channels, like the guide screenshots show, but that may just be a different between ATI and Nvidia.

Yet, in XBMC, when I set the audio to use WASAPI for both audio out and audio passthrough (with HDMI and 5.1 set), I can play test files encoded with DTS-MA and TrueHd. They work perfectly, no choppiness on either audio or video. The AVR even shows "DTS-HD MSTR" and "TrueHD" on it's console. (these are sample files HD audio files I downloaded)

Yet the guides here say "If formats are missing from this Supported Formats tab then they will not playback in XBMC, this must be fixed at the OS level first.". So how come mine do play, and play correctly, even though they aren't fixed at the OS level?

The other weird part? These files do *not* play correctly at the OS level (exactly as the guide implies). Using the latest VLC, and the latest CCCP codecs, these files do not trigger the "DTS-HD MSTR" and "TRUEHD" indicators on the AVR console. Oh, they play, but they don't trigger the AVR they way they do when I play them with XBMC.

So what am I misunderstanding? The behavior at the OS level seems consistent with the guides, but not when played through XBMC. What have I missed?

Thanks
Reply
#2
ELD is not reliable. Actually the OS plays no role for bitstreaming, the encoded stream goes through the audio device to the receiver. Important is that the required number of channels and appropriate sample rate can be opened
Reply
#3
That goes against everything I've learnt in the last 12 months on how Windows audio and AE work, for any format to pass the audio device driver must report it's capable of being passed and Supported Formats is populated by similar audio device enumeration to what XBMC does.

Admittedly I'm not a dev or a coder so don't pretend to 100% know how it all work so perhaps you know better FernetMenta on this, shame DDDamian isn't around as he'd know for certain.

MikeLeone, what does your xbmc.log show? could paste one to http://xbmclogs.com as each time XBMC is started the audio device capabilities are written to the log. Could you also share your Supported Formats window via somewhere like http://imgur.com/
Reply
#4
For bitstreaming we pass the raw data to the audio as if it were PCM (only some padding with zeros to make the data exactly fit into the intervals given by sampling rate of device). Windows and AE do not care about the encoded data format.
Reply
#5
My understanding has always been that the audio device doesn't simply pass the raw data as is, on Windows at least, the audio driver must report HD audio support to the OS.

There must be some level of software interaction, as Microsoft provided drivers from Windows update will not support being able to pass HD audio while the drivers from Nvidia on the same hardware will allow HD audio to be passed.

I'm now officially confused Huh I've provided support to hundreds of people and never has a single one of them been able to pass audio that's not shown as supported by the audio driver.
Reply
#6
(2013-08-05, 15:11)jjd-uk Wrote: MikeLeone, what does your xbmc.log show? could paste one to http://xbmclogs.com as each time XBMC is started the audio device capabilities are written to the log. Could you also share your Supported Formats window via somewhere like http://imgur.com/

I will do so when I get home from work tonight, sure. It is confusing. :-) Maybe it has something to do with Vista. Soon as I get a couple free dollars, I will replace that with Win 7. Don't like Vista anyway, but that's what came with the machine.

I will close XBMC; get the screenshot of supported formats. Then I will re-start XBMC and shut it down again, to get a log. Maybe I will play a DTS-HD MA file, and the TrueHD file, while I am at it. The AVR definitely lights up and says DTS-HD MSTR and TrueHD when I play those 2 files, but I don't see them in the Supported Formats.
Reply
#7
In the log under your HDMI device there will be a row of data starting m_dataFormats this lists what your audio device returns as being supported, so for HD audio this should include AE_FMT_DTSHD and AE_FMT_TRUEHD
Reply
#8
Quote:My understanding has always been that the audio device doesn't simply pass the raw data as is, on Windows at least, the audio driver must report HD audio support to the OS.

Not completely sure but if that is the case, we should change it. It means that we rely on maybe incorrect ELD. I see no need in letting the OS know the encoded format.
I assume that Windows just verifies ELD when passing encoded format to open device.
Reply
#9
After having looked into the code for WASAPI I share your confusion Smile
So far I have no clue why all those parameters are provided and if it's required to do so.
Reply
#10
(2013-08-05, 15:11)jjd-uk Wrote: That goes against everything I've learnt in the last 12 months on how Windows audio and AE work, for any format to pass the audio device driver must report it's capable of being passed and Supported Formats is populated by similar audio device enumeration to what XBMC does.

Admittedly I'm not a dev or a coder so don't pretend to 100% know how it all work so perhaps you know better FernetMenta on this, shame DDDamian isn't around as he'd know for certain.

MikeLeone, what does your xbmc.log show? could paste one to http://xbmclogs.com as each time XBMC is started the audio device capabilities are written to the log. Could you also share your Supported Formats window via somewhere like http://imgur.com/

Log: http://xbmclogs.com/show.php?id=42604
Screenshot: http://i.imgur.com/CN5rC0o.jpg

And yes, I see

16:33:51 T:4776 NOTICE: m_dataFormats : AE_FMT_DTSHD,AE_FMT_TRUEHD,AE_FMT_EAC3,AE_FMT_DTS,AE_FMT_AC3,AE_FMT_S24NE4,AE_FMT_S24LE4,AE_FMT_S24BE4,AE_FMT_S16NE,AE_FMT_S16LE,AE_FMT_S16BE,AE_FMT_LPCM


under "enumerated WASAPI devices", but as the screenshot shows, the OS doesn't show any of those formats..
Reply
#11
Ok, not seen Vista sound properties before and it looks to have more in common with XP than 7 which is where all the screenshots are from.

It could be that Vista doesn't understand the concept of HD audio, the important thing is that the audio device driver does which it plainly does in your case as shown by the log.

Never realised there were these differences between Vista & 7 as I went straight from XP to 7, will have to do some research.
Reply
#12
(2013-08-05, 22:00)FernetMenta Wrote: After having looked into the code for WASAPI I share your confusion Smile
So far I have no clue why all those parameters are provided and if it's required to do so.

Not sure if you're misunderstanding me or perhaps me misunderstanding you.

What governs the ability to bitstream is the driver for the audio device.

On Windows a HDCP path is required hence Microsoft drivers which don't include this will not allow HD audio. The proper device manufacturer drivers will include the HDCP support thus must always be used. It's similar on Linux is it not? Perfectly capable AMD devices are prevented from passing HD audio because of the flgx driver.

Windows does nothing to the audio when WASAPI is used, as you correctly say it's sent straight to the audio device, but the driver must then understand what's being received from XBMC before passing the audio to the HDMI out.

The driver also talks to the OS via an API telling it what audio types it can pass, this is what's shown in Supported Formats. XBMC uses this same API to talk to the audio device which is where the audio properties in the log comes from. So although the OS does nothing to the actual audio, Supported Formats indicates whether you'll be able to pass audio of a certain type. Something missing from Supported Formats will in itself not prevent audio from being bitstreamed as that is down to the audio device driver, but if the driver is not reporting it can handle a particular audio type then it will likely reject that audio type when received.
Reply
#13
(2013-08-06, 00:36)jjd-uk Wrote: comes from. So although the OS does nothing to the actual audio, Supported Formats indicates whether you'll be able to pass audio of a certain type. Something missing from Supported Formats will in itself not prevent audio from being bitstreamed as that is down to the audio device driver, but if the driver is not reporting it can handle a particular audio type then it will likely reject that audio type when received.


Yet in this case, the supported formats are only Dolby. Yet XBMC is able to send, and the driver support, DTS, DTS-HD MA, and TrueHD. The receiver lights up for each, and none are rejected.

Here's where it gets weirder .. I have no sounds in the OS. No system sounds at all. It looks like sounds are playing, the AVR console flickers, as if it's changing formats, but no sound is heard. If I connect the PC directly to the TV, with the same cable, I do get system sounds. (I still only see Dolby in the Supported Formats)

I can play media with VLC, however. Just no system sounds. But since I play all my media in XBMC, and everything plays fine in XBMC, I guess I am OK, for the moment.

Maybe in a couple weeks I will completely re-format and install Windows 7 instead. :-)
Reply
#14
That's what I'm unsure of, whether Supported Formats on Vista should show the HD formats, so while the driver supports it the reporting API in Vista might not.
Reply
#15
Quote: It's similar on Linux is it not?

Nope, on Linux we just open the device as if it were PCM. Hence there is no technical requirement of letting the OS or driver know that we send raw data. I have not figured out yet why WASAPI provides any means of setting the encoded format but I think this can be dropped.

EDIT: This was not 100% correct. On Linux the device is opened in a pass through mode but the internal format is not required.
Reply

Logout Mark Read Team Forum Stats Members Help
Confused about XBMC support for HD audio format vs OS support (Vista w/nVidia)0