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