MediaPortal Audio renderer - better video playback quality (2 Viewers)

[tontsa]

Please report what drivers and HW are returning error, since this seems to be a driver limitation WASAPI pull mode is not supported all drivers and I'm not happy if we need to add that push mode (that causes such many pops and clicks for different HW).

Vista:
C:\silence\x86>silence.exe --device "Headphones (High Definition Audio Device)"
Press Enter to quit...
Got "feed me" event but IAudioClient::GetCurrentPadding reports buffer is full -
glitch?
The thread terminated early - something bad happened
Thread HRESULT is 0x8000ffff

Driver Name: HdAudio.sys
Driver Version: 6.00.6002.18005 (English)
Driver Attributes: Final Retail

Works with HDMI:
C:\silence\x86>silence.exe --device "Digital Output Device (HDMI) (High Definition Audio Device)"
Press Enter to quit...
Aborting playback...
Received stop event after 3381 passes
Driver Name: HdAudio.sys
Driver Version: 6.00.6002.18005 (English)
Driver Attributes: Final Retail

Win7:
Works:
C:\silence\x86>silence.exe --device "Speakers (High Definition Audio Device)"
Press Enter to quit...
Aborting playback...
Received stop event after 2127 passes
Driver Name: HdAudio.sys
Driver Version: 6.01.7600.16385 (English)
Driver Attributes: Final Retail

 

[red5goahead]

Weird because do not work anymore also with V5..!!

I tried the silent test.

if I use silence --device Altoparlanti (CMI8738/8768 Audio Device) I got an error equal to audiorender.log hr = 0x80070057

D:\silence\x86>silence --device Altoparlanti (CMI8738/8768 Audio Device)
Unexpected argument count 6
silence
silence -?
silence --list-devices
silence --device "Device long name"

With no arguments, plays silence to the default audio device.
-? prints this message.
--list-devices displays the long names of all active playback devices.
--device plays silence to the specified device.CPrefs::CPrefs constructor fa
iled: hr = 0x80070057

but if use the quote:

D:\silence\x86>silence --device "Altoparlanti (CMI8738/8768 Audio Device)"
Press Enter to quit...
Got "feed me" event but IAudioClient::GetCurrentPadding reports buffer is full -
glitch?
The thread terminated early - something bad happened
Thread HRESULT is 0x8000ffff

with V5 work with the "Dispositivo digitale di output (HDMI)" device (Ati 3850)

EDIT : My mistake , these drivers drive me crazy...

with the offical last c-media driver the V5 MP audio renderer work fine as usual. I switched to the open source driver to test properly the ac3 encoding and It work fine with reclock through spd/if but not with the MP Audio renderer Version 6 (the Ac3 one). And with that driver also do not work the previous version than V5 (included ).

 

[tourettes]

Here's "silence3.exe" that will test if audio device is capable of WASAPI exclusive mode with pull / even driven support. I personaly are able to reproduce the failure with NVIDIA GPU, so the drivers are most likely to blame (I already did send an query to NVIDIA, not sure if I receive any feedback).

Usage is the same as with the MS silence2.exe:

First run:

silence.exe --list-devices

And then

silence.exe --device "long audio device name.." + the name of the audio device listed in the 1st step inside "".

 

[tourettes]

these drivers drive me crazy...

Me too

I switched to the open source driver to test properly the ac3 encoding and It work fine with reclock through spd/if but not with the MP Audio renderer Version 6 (the Ac3 one).[/B]

Did you already post a log from that case? Also what happens? Does amp's Dolby Digital light lit? Does amp still show that it receives PCM audio and produces static noise?

 

[red5goahead]

It works ! it works. My marantz display the DD 2.0 info message.

I've set the last c-media drivers (C-Media Electronics, Inc.)

into this configuration:

If I set as usual using Dolby Digital Live

It work but any sound on the default device during the playback on the digital device cause a pc shutdown (even the bios will be reset!!)

 

[tourettes]

It works ! it works. My marantz display the DD 2.0 info message.

Thanks for the patience in testing. Now we have a confirm that the AC3 encoding is working. I'll continue to digg that NVIDIA GPU related issue while multisound code is brewing

It work but any sound on the default device during the playback on the digital device cause a pc shutdown (even the bios will be reset!!)

Quite nasty driver / hardware bug there

 

[red5goahead]

two logs when speedup pal is on the run.

 

[tourettes]

two logs when speedup pal is on the run.

2nd one seems to log some dropped audio data. Does it happen with the non-AC3 encoding mode as well? Same sample file (The.Pacific.1x05.iNTERNAL.720p.HDTV.mkv) seems to play nicely on my dev PC with AC3 encoding enabled.

It could be:

1) some additional change on the current code base
2) difference in HW (a bug in audio renderer)

 

[red5goahead]

two logs when speedup pal is on the run.

2nd one seems to log some dropped audio data. Does it happen with the non-AC3 encoding mode as well? Same sample file (The.Pacific.1x05.iNTERNAL.720p.HDTV.mkv) seems to play nicely on my dev PC with AC3 encoding enabled.

It could be:

1) some additional change on the current code base
2) difference in HW (a bug in audio renderer)

remember that file ? it had a problem with the 32 bit IEEE float decode from ffdshow. it did'nt play . I installed a new ffdshow version (July 27 I guess). Now start but with no sound. I'll try disabling the ac3 encoder. Anyway imho we should have the same version of ffdshow .
note : a new WASAPIPreferredDeviceForBitstreaming registry key would be useful.

 

[tourettes]

remember that file ? it had a problem with the 32 bit IEEE float decode from ffdshow. it did'nt play . I installed a new ffdshow version (July 27 I guess). Now start but with no sound. I'll try disabling the ac3 encoder. Anyway imho we should have the same version of ffdshow ..

That would help troubleshooting the HW / driver issues, but in general it is much better to have different ffdshow versions so we can see if there are bugs in audio renderer (or ffdshow itself) that are requiring the

note : a new WASAPIPreferredDeviceForBitstreaming registry key would be useful.

Yes, but that would require new code as well (bitstreaming or at least detecting the bitstreanable content). This depends highly how ffdshow has been implemented and if it is providing enough information.


But it wll come later...