> 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
