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