Re: safe support for rewind in ALSA

[pl bossart <bossart.nospam@gmail.com>]

> 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.

Thanks Jaroslav.
I was under the impression that the runtime->delay indicated the time
needed for transmission and D/A. If this is intended to be the queued
samples, then it plays the same role as my 'fifo' proposal. There are
several consequences though:
- This means rewind() can only happen within the ring buffer, and all
samples previously queued will be played as is.
- the 'only' change is to make sure the hw_ptr reported in .pointer is
NOT the number of samples pushed out to the interface. hw_ptr should
really represent the next read position in the ring buffer, this isn't
uniform across drivers. This means for example that the HDAudio
implementation needs to modified so that the LPIB value is increased
with runtime->delay.
- How do you specify the time for transmission and D/A, so that
applications can know when a sample will actually be played. With your
explanation the applications can only know when a sample will be
pushed out, there is an additional latency not accounted for.
Thanks for your feedback.
- Pierre