GetCurrentPadding need not call snd_pcm_avail_update
Joerg-Cyril.Hoehle at t-systems.com
Joerg-Cyril.Hoehle at t-systems.com
Mon Aug 8 06:18:38 CDT 2011
Hi,
GetCurrentPadding (GCP) is defined as
write_pos - play_pos modulo GetBufferSize
write_pos is what the next GetBuffer returns: the next unwritten position.
play_pos is what the next snd_pcm_write will receive: the position of the
frame to send to ALSA next.
If you simplify the current code such that solely the periodic thread
writes to the underlying ALSA device, then play_pos is never updated
outside that thread -- except by Reset. Therefore, there's no need to
call snd_pcm_update_avail outside that thread.
That change is consistent with native's observable behaviour in SHARED mode.
GCP is decremented by 480 frames here and then, corresponding to 10ms
chunks that the audio engine drains from the app's buffer and sends to
the mixer. It is not decreasing continuously.
See http://www.winehq.org/pipermail/wine-devel/2011-August/091371.html
As an optimization, Wine's ReleaseBuffer calls snd_pcm_write when the buffer
is empty to accelerate (re)starting. Call snd_pcm_avail_update and
update play_pos there, still no need to call it from within GCP.
Why does the value returned by GCP matter? The experience is that we
see bug reports whenever Wine does not match native's dynamic
behaviour as closely as possible.
Regards,
Jörg Höhle
More information about the wine-devel
mailing list