Re: PCM API update

[Abramo Bagnara <abramo.bagnara@libero.it>]

Jaroslav Kysela wrote:
> 
> On Fri, 11 Oct 2002, Abramo Bagnara wrote:
> 
> > I really don't understand why you've added another ioctl and another
> > function to replicate in all PCM classes.
> > snd_pcm_delay existence is enough to implement that.
> > I'm missing something?
> 
> You're completely right, but in my eyes, the avail ioctl looks much better
> for kernel space (it's a base value for computing delay, computing avail
> from delay needs twice substractions which doesn't look very good).
> Unfortunately, delay ioctl was first, and we should keep binary
> compatibility for 2.5, so we should leave both ioctls there. In library,
> we can remove the delay operation from chains and use avail to compute it
> as well to simplify code.

No, you can't.
The semantic of snd_pcm_delay is:
"How many frames are current application read/write pointer far away
from 'now' (i.e. real world sound)?"

It's *not* simply equivalent to buffer_size - avail (playback) or avail
(capture). It's designed to take in account also olatencies introduced
by other things (network layer, hardware limits, etc.).

Although I don't understand why you think that snd_pcm_avail is needed
when we have the right (and safe) snd_pcm_avail_update, it can be
implemented calling snd_pcm_delay (so to update hw pointer) and then
computing the avail count using the mmap'ed counters.

Of course this can't work for chained PCM (and this is why we have
snd_pcm_avail_update).

I think you should revert your patch (and to force yourself to believe a
bit more in peer review before important changes although it seems I'm
beating a dead horse here).

-- 
Abramo Bagnara                       mailto:abramo.bagnara@libero.it

Opera Unica                          Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf