On Fri, 13 Jun 2008, Colin Guthrie wrote:
James Courtier-Dutton wrote:
Jaroslav Kysela wrote:
On Fri, 13 Jun 2008, Takashi Iwai wrote:
- Add some new API functions,
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 what snd_pcm_delay() was introduced into the ALSA api for. I remember, because it was added as a result of me requesting it.
Then implement a totally different api call to help with under run timings.
Big +1
You also have to think of the use cases currently out there.
- World + Dog uses it as James (and Lennart) states.
- Wine uses it sans latency.
The comment for snd_pcm_delay() in alsa-lib is clear and it's what James wrote. If only one app interprets this wrongly, then I agree it would be better not to change original meaning.
Then we have snd_pcm_avail_update(). Although it is stated in comment that this function is useless for non-mmap mode, it's quite clear that returns number of available frames to be handled (r/w) by application.
The easiest method would be just to remove "useless for non-mmap" from comments for snd_pcm_avail_update() and suggest to application developers:
1) overall latency is returned by snd_pcm_delay() 2) ring buffer filling is controlled by snd_pcm_avail_update(), for non-mmap access is usage of this function optional
As mentioned, it will need to fix some drivers mixing software output FIFO with ring buffer (USB, PCMCIA)..
Opinions?
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.