Re: safe support for rewind in ALSA

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

2010/2/2 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
>
>
if snd_xxx_pointer call back return the next read position , the hw_ptr will
always be multiple of PCI/PCIe brust size