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