At Thu, 12 Jun 2008 22:52:25 +0200, Lennart Poettering wrote:
You didn't respond to my suggesion to add a second function,
Hm, which function? I seem to have missed that.
so that we'd have two: one that includes the extra delay after hw_ptr, and the other that does not. The former would then be useful for audio/video sync, the latter for estimating when an underrun will happen. Would it be possible to add this?
Indeed, there are two problems in the background: - the period irq model - no latency assumption
The period irq model is what you called "traditional playback model". No latency assumption in hwptr comes from the PCI-style hardware.
About the latency, my proposal is like below:
- Renew the definition of hwptr -- make it what you imagned, the pointer where hardware is reading or has read.
This won't change anything for PCI drivers, so the impact is minimal.
- Add some new API functions, * To give the accuracy of the position inquiry (optional)
This requires some new kernel <-> user-space stuff.
* To query the known latency
Ditto, or we may reuse snd_pcm_hw_params_fifo_size()?
* To query the position being played (optionally)
This can be simply hwptr + latency.
- Don't change snd_pcm_delay(). Keep as is now.
About the period model -- it's a bit more tough problem. I once already made a patch to allow user-apps to use a system timer for more flexible period settings. But, it was for very old version of ALSA. Better to write from the scratch again...
Takashi