Hi.
I develop windows device drivers and am testing a driver against the WASAPI 3.0 plugin.
This plugin apears to have a bug:
Sometimes it gets stuck between songs of different sample rates and juut stays there at the beginning of the new song. When this happens the device driver never receives a STOP state and never is requested to change sample rates.
When this happens the device driver simply stops receiving audio packets, and continues to get polled for audio position. When it works, there are either 0 or 1 position polls before the stream is stopped (STOP state). So, either it hangs for good or it works immediately. If I stop playback everything works again. It may have something to do with the fact that my buffer position advances with very high precision. It almost seems that if the plugin sent the last packet, and it it then manages to poll the position 2 times, this causes it to go into a weird state of waiting for the buffer position to stop moving (which it is not suppsed to do until exiting the RUN state.
If I modify the driver to stop advancing the postition when it runs out of audio packets, then foobar no longer gets stuck. I can't release my driver like that since this violates Microsoft specs.
Cheers
Philip
Sometimes it gets stuck between songs of different sample rates and juut stays there at the beginning of the new song. When this happens the device driver never receives a STOP state and never is requested to change sample rates.
I had also exactly the same behavior here with two songs.
Now I checked again: flac has 44.1kHz and mp3 has 48kHz
Sometimes foobar hangs at beginning of 2nd song, position slider disappears and flickers.
Until I click on slider or double click the song to resume playback.
intel d525mw, atom d525, w7x64sp1 upd, foobar 1.1.18, only official components, wasapi push 200ms, buffer 500ms, realtek hda -> speaker
Yes, I can confirm that this is EXACTLY the same behaviour I see. THis must be a WASAPI plugin bug...
Does anyone know how to get in touch with Pete (I think he is the author), in order to get this fixed?
Cheers
Philip
Problem acknowledged, thanks for reporting.
Beta version:
http://www.foobar2000.org/temp/WASAPI-beta....fb2k-component (http://www.foobar2000.org/temp/WASAPI-beta/WASAPI-3.1-b1.fb2k-component)
No changes since 3.0 other than this fix.
Beta version:
http://www.foobar2000.org/temp/WASAPI-beta....fb2k-component (http://www.foobar2000.org/temp/WASAPI-beta/WASAPI-3.1-b1.fb2k-component)
No changes since 3.0 other than this fix.
Thanks for the quick fix. 3.1 appears to fix this. I will do some more testing and let you know if there are any problems.
Cheers
Philip
Beta version:
http://www.foobar2000.org/temp/WASAPI-beta....fb2k-component (http://www.foobar2000.org/temp/WASAPI-beta/WASAPI-3.1-b1.fb2k-component)
No changes since 3.0 other than this fix.
Hi Pete. Doing further testing shows that WASAPI push now works reliably, but there appears to be a problem with WASAPI event mode.
It appears that you are calling IAudioClient->Initialize() with the periodicity parameter set to about 10ms. This will sometimes cause event mode to underflow the buffer of WaveCyclic miniport drivers which have a DPC periodicity of 10ms, causing the well known popping/clicking effect. This could be solved by setting this parameter to 15ms (5ms higher than required) or even 20ms.
I'm not 100% sure about this but if you provide a test build I can confirm whether or not this theory is correct.
Cheers
Philip Gruebele
It appears that you are calling IAudioClient->Initialize() with the periodicity parameter set to about 10ms. This will sometimes cause event mode to underflow the buffer of WaveCyclic miniport drivers which have a DPC periodicity of 10ms, causing the well known popping/clicking effect. This could be solved by setting this parameter to 15ms (5ms higher than required) or even 20ms.
Try changing Preferences > Advanced > Playback > WASAPI > Hardware buffer in MS - event mode
It appears that you are calling IAudioClient->Initialize() with the periodicity parameter set to about 10ms. This will sometimes cause event mode to underflow the buffer of WaveCyclic miniport drivers which have a DPC periodicity of 10ms, causing the well known popping/clicking effect. This could be solved by setting this parameter to 15ms (5ms higher than required) or even 20ms.
Try changing Preferences > Advanced > Playback > WASAPI > Hardware buffer in MS - event mode
I am trying that now, thanks. It appears to work but I will test a bit more. The WASAPI plugin should call IAudioClient::GetDevicePeriod() to obtain the correct default no? If not, any chance this can be changed to 15 by default? That would save a lot of people a lot of headaches...