Hi all,
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 about.:)
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 ideas?
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) APIs...