Subject: Re: safe support for rewind in ALSA
Date: Monday 1st February 2010 21:54:55 UTC (over 8 years ago)
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...