[Windows] AudioEngine testers - Windows platform only

@PanDaMan - DaniellaE's branch will also be clipping, this is an existing issue, what's different is that AE reports it so we know when it occurs. We are currently working on a DRC patch that will help with this behaviour instead of just clamping the buffer. (We never output clipped audio, we have a soft clamper that performs a poor mans DRC to the samples when this occurs).

(2012-04-28 09:43)wints Wrote:  Hi guys and girl great work hdmi switching problem is sorted for me but i now have no audio in tv series what are mp3? cheers for any advice

Sorry to ask again but is this just happening to me? or is it a known problem? they used to play fine in the last build, cheers again

Hi wints - if you're using the latest please post a log and I'll take a look - thx.

ok cheers DDDamian http://xbmclogs.com/show.php?id=2092

Interesting - if unexpected - nothing too unusual, just a 48khz mp3. I have the same GPU on my main machine, so should be able to repro easily enough.

I'm on it

EDIT: @wints - no issues here on video with mp3 48khz audio - log shows everything normal - is your volume up? Press "+" key? Do normal mp3's (music) play okay?

(2012-04-30 12:37)gnif Wrote:  @PanDaMan - DaniellaE's branch will also be clipping, this is an existing issue, what's different is that AE reports it so we know when it occurs. We are currently working on a DRC patch that will help with this behaviour instead of just clamping the buffer. (We never output clipped audio, we have a soft clamper that performs a poor mans DRC to the samples when this occurs).

@gnif - Thanks. I did not hear any distortion with DaniellaE's, I also don't hear anything or get any clamping logged if I set the volume in guisettings to 0.999999 which should be close enough to 1.0 not to matter. See http://xbmclogs.com/show.php?id=2103
My C is very rusty, but wouldn't the missing 'f' suffix on line 939 in SoftAE.cpp mean it's being compared as a double rather than float and could the promotion be marginal making it think it needed to clamp when it didn't?

By "poor man's DRC" did you mean the tanh approximation? That looks well off for values |x| > 0.5 if I'm reading the plot here correctly: http://bit.ly/Jx4ULG Applying this only on blocks with values > 1.0 means there's additional non-linearity between blocks that get clamped and those that don't. That might also cause the distortion I was hearing.

Finally, the SSE clamp looks broken, implementing (x * (c1 + x^2)) / (c2 + x^2). c2 should just be 9.0f and an additional multiply operation is needed (x * (c1 + x^2)) / (c1 + (c2 * x^2))

hi DDDamian,
is it possible to initialize wasapi exclusive everytime a movie get start to prevent handshake errors?
because i ordered a pulseeight cec adapter and i am afraid to get more errors than success.

@Nimo - it is almost certain that each time you play a movie the wasapi device will be re-initialied. The reason is we default to 2ch 44.1khz pcm when no stream is playing as every windows-compatible audio device *must* support that format. As soon as you play anything different the device is re-initialized to match the format of the stream, whether its a passthrough format or another pcm format with a different bitdepth, channel layout or sample rate.

Unfortunately that is not the same as handshaking, which does not automatically occur when you reinitialize for a new format. This is controlled by the firmware in your hardware, whether receiver or TV, and a major failure of the HDMI specification implementation for many manufacturers. Sometimes the device itself needs to be powered off and on, sometimes just switching the input to another and back is enough. There is no way from the PC end to force this to happen.

@PanDaMan - nice analysis - needs looking into for sure. Haven't run across this yet even with very "hot" tracks unless downmixing, but without having had time to dig deeper certainly a float/double conversion alone can introduce tiny errors - fp math can return unexpected results with very small comparisons, e.g around 1.0 but not quite 1.0. Any soft-clipper will produce distortions by nature, and it is in there as the final blocker to hard-clipping. If you weren't downmixing there should be no values >1.0, so we need to re-check the math there. Thanks for pointing it out as we hadn't run across it at all.

Hello again,

after I figured out that you need something called PAP (Protected Audio Path) as a feature on your graphics card to bitstream the HD sound things I tried testing with my Desktop Computer(ATI Radeon HD5750). Obviously the GF9300 of my HTPC does not support PAP :-(
Here are the results:

Selecting WASAPI: Realtek HDMI (ATI HDMI) in Options got me no sound, so i tried it with Directsound: Realtek HDMI (ATI HDMI) and it worked
Tested the following files, of which none was working:

• DTSHD-MA 7.1 sample track from here (hd_dts_sfx_long_lossless.m2ts):
  Very low framerate during the whole clip (about 6 fps), on the first try the Receiver got a DTSHD-MA signal after 2 seconds but there was no sound(besides from some clicking noise every 0.5 seconds)
  On second try, 10 minutes later the receiver stayed blinking 'HDMI' the whole clip, no detection of the correct DTSHD-MA audio.
  Third try there was the correct signal again, but still only the clicking noise (like the first time)
• Dolby TrueHD 7.1 sample track from demo-world as well (hd_dolby_spheres_lossless.m2ts):
  Same very low framerate, receiver stayed on AllChStereo and there was a very disturbing technical scratch noise on all of my speakers (don't know how to describe it better :-P ) I stopped the clip immediately.
• MKV with DTSHD-MA 5.1 track (8 Blickwinkel - 1080p (DTSHD-MA Deutsch).mkv):
  Same problems like the first sample file. I switched to english sound which is normal dolby and it worked correctly with the correct framerate. Back to the german DTSHD-MA and it juddered again.
  

So here is my debug log, i hope it helps you:
http://xbmclogs.com/show.php?id=2124

@Hasu0bs - PAP is meant more for adding in third-party software as DSPs and other sound-processing elements into the Windows audio layer, an ideal place for a virus and thus the protected status. The GF9300 is not hardware-compatible with bitstream formats.

You cannot bitstream HD audio formats through DirectSound - it is only capable of spdif formats like AC3 (Dolby).

Your HD5750 will bitstream just fine. You don't mention the driver version/date for the RealTek driver, but I'd start by removing that in the Control Panel under Device Manager, then downloading the latest Catalyst Control Center v12.3 and installing it. Be sure that the driver now listed in Device Manager is the AMD/ATI HDMI High Definition Device, and that you have set it's properties correctly, especially checking the two boxes on the Advanced tab and disabling any enhancements.

Select this as your audio device in XBMC-AE and everything should work fine. Again, do not use DirectSound for TrueHD/DTS-MA - it won't work.