[alsa-devel] What does snd_pcm_delay() actually return?

[Takashi Iwai]

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