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

[Lennart Poettering]

On Fri, 13.06.08 11:14, James Courtier-Dutton (James at superbug.co.uk) wrote:

> > I would prefer to extend the current API than to change meaning of hw_ptr 
> > to handle extra latencies.

> I would prefer the definition of snd_pcm_delay() to be:
> Before the next sample is written to the buffer, snd_pcm_delay() returns 
> the expect time delay, in frames, indicating the time the next sample 
> will reach the speakers.

This is how I always understood the API. 

OTOH I actually can understand the WINE folks, that they want to have
an API that can be used to query how much of what has already been
written is still unplayed. Why? because snd_pcm_delay() in your
definition would return the time in samples *in the sound card time
domain*. To emulate what they need from this value is quite hard,
because you'd need to deal with deviating system/audio clocks. It's
pain.

(And that's why I'd love to see that much more generic
snd_pcm_get_timing() call implemented, which supports all of these
timing parameters)

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4