MediaPortal Audio renderer - better video playback quality (1 Viewer)

[tourettes]

I think the drivers are a bit broken, since GetBuffer call to WASAPI is returning no error and still it manages to produce invalid buffer for the driver side that the actual audio data should be written. Good thing is that even MS thinks the GetBuffer should always provide a valid buffer since their example code is assuming that if no errors are reported the buffer will be valid.
In the mean time could you check if there are new audio drivers available and another thing would be to try a different audio chip if possible.

Please note this: I tried to install the wasapi plugin for FooBar2000 to test that kind of framework. It work .

I'm sure that WASAPI works on that card, but there still could be some bugs in the drivers that are just triggered audio renderer's code. Or it could be simply a bug in audio renderer's code, but it should do it on all HW. I haven't ever seen the GetBuffer call to fail and I have tested hundreds of hours of playback.

Here's the next version of that workaround. Now when the GetBuffer fails it will test 100 times to first release the buffer that was NULL and then request a new one. Every atempt has 5 ms period of sleep. Just lets see if the buffer will be available in the 500 ms period. If not I'm quite unsure what could be the next step to try.

I guess one thing could be to try to disable the WASAPIExclusive as disabled, if you haven't already tried it.

 

[red5goahead]

No change. I attach the log.
instead with WASAPIExclusive disabled (=0) the filter graph do not use new renderer but the default one (direct sound...)

 

[red5goahead]

the audiorender log when I 've disabled WASAPIExclusive .

with WASAPIExclusive = ON
14-07-2010 22:24:44.689 [112c]WAVEFORMATEX:
14-07-2010 22:24:44.689 [112c] nAvgBytesPerSec 192000
14-07-2010 22:24:44.689 [112c] nBlockAlign 4
14-07-2010 22:24:44.689 [112c] nChannels 2
14-07-2010 22:24:44.689 [112c] nSamplesPerSec 48000
14-07-2010 22:24:44.689 [112c] wBitsPerSample 16
14-07-2010 22:24:44.689 [112c] wFormatTag 1
14-07-2010 22:24:44.689 [112c]CheckAudioClient First initialization of the audio renderer
14-07-2010 22:24:44.689 [112c]InitAudioClient
14-07-2010 22:24:44.700 [112c]InitAudioClient format supported
14-07-2010 22:24:44.711 [112c]InitAudioClient service initialization success
14-07-2010 22:24:44.716 [112c]SetBias: 1.0000000238
14-07-2010 22:24:44.716 [112c]SetBias - updated SoundTouch tempo
14-07-2010 22:24:44.738 [1480]DoRenderSampleWasapi Starting audio client

with WASAPIExclusive = OFF
14-07-2010 22:34:46.575 [14e4]CheckMediaType WASAPI client refused the format, used mix format:
14-07-2010 22:34:46.575 [14e4]WAVEFORMATEX:
14-07-2010 22:34:46.575 [14e4] nAvgBytesPerSec 1058400
14-07-2010 22:34:46.575 [14e4] nBlockAlign 24
14-07-2010 22:34:46.575 [14e4] nChannels 6
14-07-2010 22:34:46.575 [14e4] nSamplesPerSec 44100
14-07-2010 22:34:46.575 [14e4] wBitsPerSample 32
14-07-2010 22:34:46.575 [14e4] wFormatTag 65534
14-07-2010 22:34:46.575 [14e4] WAVE_FORMAT_EXTENSIBLE
14-07-2010 22:34:46.575 [14e4] dwChannelMask 1551
14-07-2010 22:34:46.575 [14e4] GUID {00000003-0000-0010-8000-00AA00389B71}
14-07-2010 22:34:46.880 [14e4]Pause
14-07-2010 22:34:47.073 [b48]Run
14-07-2010 22:34:47.073 [b48]CheckAudioClient
14-07-2010 22:34:47.076 [b48]SetBias: 1.0000000238
14-07-2010 22:34:47.076 [b48]SetBias - updated SoundTouch tempo
14-07-2010 22:35:29.912 [14e4]Pause
14-07-2010 22:35:29.921 [14e4]Stop
14-07-2010 22:35:29.921 [14e4]Stop - releasing WASAPI resources

quite different but the source in the same....

 

[tourettes]

with WASAPIExclusive = OFF
14-07-2010 22:34:46.575 [14e4]CheckMediaType WASAPI client refused the format, used mix format:
14-07-2010 22:34:46.575 [14e4]WAVEFORMATEX:
14-07-2010 22:34:46.575 [14e4] nAvgBytesPerSec 1058400
14-07-2010 22:34:46.575 [14e4] nBlockAlign 24
14-07-2010 22:34:46.575 [14e4] nChannels 6
14-07-2010 22:34:46.575 [14e4] nSamplesPerSec 44100
14-07-2010 22:34:46.575 [14e4] wBitsPerSample 32
14-07-2010 22:34:46.575 [14e4] wFormatTag 65534
14-07-2010 22:34:46.575 [14e4] WAVE_FORMAT_EXTENSIBLE
14-07-2010 22:34:46.575 [14e4] dwChannelMask 1551
14-07-2010 22:34:46.575 [14e4] GUID {00000003-0000-0010-8000-00AA00389B71}

non-exclusive mode doesn't work because the shared WASAPI mode requires the application to match the output to the target device or actually the currently used mixing format. Basicly it currently works in some cases, but not in the most.

Too bad that MS doesn't provide any sample rate conversion with WASAPI. Applications need to implement it by itself (and that will be done on later step for MP audio renderer).

 

[tourettes]

No change.

A new binary... contains a bit more logging and few minor changes (I really hate when I cannot debug something on the dev PC itself...)

 

[red5goahead]

No change.

A new binary... contains a bit more logging and few minor changes (I really hate when I cannot debug something on the dev PC itself...)

Me too... I dev in Delphi since 1996 and in c# since 2 years. Sometimes is a nightmare...

Now the sound has been played correct with a lot of clicks . It's still desynched.

Attached the new log.

 

[tourettes]

No change.

A new binary... contains a bit more logging and few minor changes (I really hate when I cannot debug something on the dev PC itself...)

Me too... I dev in Delphi since 1996 and in c# since 2 years. Sometimes is a nightmare...

Now the sound has been played correct with a lot of clicks . It's still desynched.

Attached the new log.

Too bad. I'll go thru the workaround code once again this evening and if that doesn't work I think I have to set the C-Media CMI8768+ based audio HW as incompatible with the MP Audio Renderer for now. To me it looks that there would be something odd happening on the driver / WASAPI framework level. The code that fills the buffers is quite straight forward when it interacts with the WASAPI it just ask a new buffer with GetBuffer method and that returns an invalid buffer (NULL pointer) and says all went ok. Some things that need to be checked:

1) amount of buffer requested - maybe this is zero on those failed cases?
2) add registry setting(s) to allow modify few settings that are related to the buffer initialization code.

If those wont work, then I think we must put this issue on hold and hope that it will be fixed when we are going to implement the multichannel support (since the idea was to change from push to pull mode when providing the data. Althou at least Google seems to say that WOW64 and event driver mode in WASAPI is broken on EVERY SINGLE AUDIO CARD on Vista. Good work Microsoft if that is true ).

About that desynced. Was the MP audio renderer producing a delayed lip sync (longer recording)? Also did you try that default directsound renderer and compare it's recording to the MP one? (sorry cannot remember )

 

[tourettes]

red5goahead, if you can take a system image / whole backup. Could you try if following drivers are 1) working on your hardware 2) change the behavior of MP audio renderer?

CMIDriver-1.2.6-bin-x86-WaveRT.zip from cmediadrivers - Project Hosting on Google Code

 

[red5goahead]

red5goahead, if you can take a system image / whole backup. Could you try if following drivers are 1) working on your hardware 2) change the behavior of MP audio renderer?

CMIDriver-1.2.6-bin-x86-WaveRT.zip from cmediadrivers - Project Hosting on Google Code

If they are compatible also with 8768+ the chip with Dolby Digital Live feature so glad to try.

 

[Owlsroost]

Out of curiosity, why the concentration on getting WASAPI working at this early stage ?

My memory of the fun-and-games James had when WASAPI support was added to ReClock suggests that it's not very well implemented by some sound drivers, and surely getting the core functionality tested by as many people as possible using DirectSound is the important first step, followed by multi-channel support.

As far as I can see, the main feature WASAPI gets you is the ability to control the output channel format over HDMI to match the source e.g. so that stereo is seen as stereo by the AV receiver and doesn't get upmixed by Windows to match the speaker layout set in the sound control panel. WASAPI doesn't guarantee 'bit-perfect' output, it's just a more direct way of talking to the sound drivers, like ASIO (and KS on XP) - as far as I know.

Tony