http://bugs.winehq.org/show_bug.cgi?id=28622
--- Comment #51 from Andrew Eikum aeikum@codeweavers.com 2012-10-01 10:05:38 CDT --- (In reply to comment #50)
o It's time to add and use: #define QUIRK_PULSE 1 with make_handle_underrun_config: This->quirks |= QUIRK_PULSE;
Yeah, maybe, but that's a separate issue. This is intended to work better with how ALSA is intended to be used (unreliable timers, so don't rely on avail_update() to determine buffer fullness). We want this behavior in all cases.
o if(err < 0 || alsa_period_us < period / 10) Formerly, the check err<0 followed snd_pcm_hw_params_set_period_time_near Now you have a larger cascade involving err<0. Does it do what you want?
Yeah, I got it a little confused. I'll review that entire sequence, thanks for finding it.
o AudioClient_Start
- if(This->dataflow == eRender){
snd_pcm_avail_update(This->pcm_handle);What's the purpose of this? IIRC, PA's avail_update was unreliable before it had really started (or am I confusing that with OSS?).
It's a leftover from when I tried to use snd_pcm_htimestamp(), which turned out to be unusable. I'll remove it.
o There are now 3 timers
- CreatetimerQueue
- gettimeofday
- the ALSA device's timer
None of these are sync'ed. I doubt anybody can prove that the code works correctly in the long run. That's my big conceptual gripe.
I too got the feeling that PA might behave when it's not fed too much data, but how to best achieve that without introducing clock skew issues?
The biggest issue here is using gettimeofday() instead of snd_pcm_htimestamp(). With htimestamp(), the clock skew would be detected and corrected by the while(diff > period) loop. Unfortunately htimestamp() is unusable. The nice thing about gettimeofday() is that it will always work regardless of ALSA bugs, so I wonder if it isn't worth just ignoring the clock skew issue and letting it under/overrun on occasion.
I'd like to submit this patch very soon, but it would be nice to get confirmation that it works from someone who has been having problems.