Re: safe support for rewind in ALSA

[Raymond Yau <superquad.vortex2@gmail.com>]

2010/2/2 Jaroslav Kysela <perex@perex.cz>

> On Mon, 1 Feb 2010, pl bossart wrote:
>
> > All,
> > I'd like to reopen a thread on concerns with the current
> > implementation of rewind in ALSA. This was already discussed on the
> > mailing list last year without any progress.
>
> I don't think that there have been no progress. The queued samples can be
> stored to runtime->delay now, so snd_pcm_delay() returns a correct
> value.
>
> The snd_pcm_rewind() and snd_pcm_forward() functions should operate in the
> ring buffer and it's ok. See the USB driver for an example. Just add
> support for runtime->delay to the lowlevel drivers and use snd_pcm_delay()
> correctly in the user space and everything will work as expected.
>
> In other words - for hardware with large FIFOs, the runtime->delay should
> be used for queued samples and the hw_ptr in the ring buffer should be
> increased as soon as the FIFO is filled with samples from the ring buffer.
>
>                                        Jaroslav
>
>
Are there any demo program using snd_pcm_rewind()/snd_pcm_forward() to
verify the driver meet  your proposal  ?

For the interrupt driven model, the application fill the period while the
driver playing the other period on two periods per buffer , the drivers
don't need to provide accuracy up to a few sample derivation.

However It seem to me that your proposal give an impression to the
application developer that all ALSA drivers can  provide accuracy up to
sample accuracy