2012-02-06, 17:37
Wow - a flurry is right! Just to address a few items I read through in no particular order, maybe as a primer:
Testing this without the bitstreaming aspects is a bit of a moot point. XBMC already decodes TrueHD to PCM at 16bit. This patch is for straight passthrough of TrueHD and >core-DTS. There is no decoding of DTS-MA to PCM, only the core DTS.
TrueHD *can* run up to 24/192 8-channel. In reality it seldom has this amount of information in it.
In either case there are still limitations of 16bits in the base ffmpeg code and further along.
WASAPI is not the same as the audio driver. Windows users have two choices regardless of their driver - WASAPI and DirectSound. DirectSound handles Windows mixing/resampling. When you talk to DirectSound it tells you what sample rate it is running at, as set in your audio settings, and it remixes everything to that forrmat. When you talk to WASAPI you tell it what to output, and skip the resampling. If this doesn't match your Windows settings you override them. You are negotiating with the audio driver for the best format it can handle, ideally your source format. This can be to the exclusion of all other apps seeking audio output (Exclusive mode) or at a compromise format (Shared mode).
The purest audio output is going to be in WASAPI exclsive mode - you bypass the Windows mixer and any resampling/mixing. Most modern audio hardware will handle the source format whether it's 2ch 16/44.1 or 8ch 24/192. While in this mode no other system sounds can play - only XBMC streams.
Even in this mode there are two choices - timed or event-driven. In timed mode the app has to present new data before the buffer runs dry using delays. In event-driven mode Windows calls you back to let you know it needs new data.
With this patch there are still the 16-bit limitations and timed polling, which AE does improve upon, but obviously is still a WIP.
Hope the little primer helps!
Testing this without the bitstreaming aspects is a bit of a moot point. XBMC already decodes TrueHD to PCM at 16bit. This patch is for straight passthrough of TrueHD and >core-DTS. There is no decoding of DTS-MA to PCM, only the core DTS.
TrueHD *can* run up to 24/192 8-channel. In reality it seldom has this amount of information in it.
In either case there are still limitations of 16bits in the base ffmpeg code and further along.
WASAPI is not the same as the audio driver. Windows users have two choices regardless of their driver - WASAPI and DirectSound. DirectSound handles Windows mixing/resampling. When you talk to DirectSound it tells you what sample rate it is running at, as set in your audio settings, and it remixes everything to that forrmat. When you talk to WASAPI you tell it what to output, and skip the resampling. If this doesn't match your Windows settings you override them. You are negotiating with the audio driver for the best format it can handle, ideally your source format. This can be to the exclusion of all other apps seeking audio output (Exclusive mode) or at a compromise format (Shared mode).
The purest audio output is going to be in WASAPI exclsive mode - you bypass the Windows mixer and any resampling/mixing. Most modern audio hardware will handle the source format whether it's 2ch 16/44.1 or 8ch 24/192. While in this mode no other system sounds can play - only XBMC streams.
Even in this mode there are two choices - timed or event-driven. In timed mode the app has to present new data before the buffer runs dry using delays. In event-driven mode Windows calls you back to let you know it needs new data.
With this patch there are still the 16-bit limitations and timed polling, which AE does improve upon, but obviously is still a WIP.
Hope the little primer helps!