[alsa-devel] safe support for rewind in ALSA
kvehmanen at eca.cx
Mon Feb 1 22:54:55 CET 2010
and then about the "other problem", e.g. of rewinding with drivers/HW that
do burst transfers of samples from ALSA ringbuffer to a separate HW
buffer. Uh oh, and what the subject says this thread is ought to be
On Mon, 1 Feb 2010, Kai Vehmanen wrote:
> So while snd_pcm_delay() provides a snapshot of the delay at the last DMA
> burst/block-transfer (when hw_ptr+runtime->delay were last updated in the
> driver), the information may be refined with snd_pcm_status_get_tstamp(),
> which essentially tells the diff between T1&T3. So essentially what the
> application is looking for is 'snd_pcm_delay()-(T3-T1)'.
> One idea is to tie this to the existing SNDRV_PCM_INFO_BATCH flag (e.g.
> quoting existing documentation in pcm_local.h -> "device transfers samples in
> batch"). So if the PCM has this flag set, application should interpret
> snd_pcm_delay() results as referring to the last batch.
Maybe the same INFO_BATCH flag could be used to help solve the rewind
problem as well. If set, it is a signal that a segment of the ringbuffer
(N samples after current hw_ptr) may have been already transferred, or is
currently in transfer, and cannot be rewound (without stopping the stream
and causing a glitch), but the elapsed callback and hw_ptr have not yet
occured. And most importantly, when pointer() cb reports that hw_ptr jumps
in bursts, so current snd_pcm_rewindable() implementation may not be
accurate with these drivers.
But then how much is N? I guess we can't assume N=period-size (does not
apply for e.g. how pulseaudio uses ALSA in glitch free mode).
Sw-params:xfer-align is not the same thing plus it's now deprecated. Any
Hmm, or on a second though, maybe N=period-size is a good idea after all.
E.g. drivers would configure the DMA transfers according to the
hwparams:period-size, and apps such as pulseaudio could decide (by setting
the period-size) how close to hw-ptr it wants to live (and still rewind if
needed). Of course, it's not obvious how useful PA glitch-free is if used
in this way...
For applications, this would be hidden in the implementation of
snd_pcm_rewindable() and snd_pcm_rewind() (they would check for
INFO_BATCH and limit rewinding appropriately).
PS Like with my earlier mail, I'm not 100% convinced this is a generic
enough approach (or if the wider community thinks this is
a serious enough of a problem), but with these proposals I'm
thinking what can be done within the scope of current (driver)
More information about the Alsa-devel