At Fri, 13 Jun 2008 17:02:47 +0200 (CEST), Jaroslav Kysela wrote:
On Fri, 13 Jun 2008, Lennart Poettering wrote:
On Fri, 13.06.08 15:06, Jaroslav Kysela (perex@perex.cz) wrote:
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:
- overall latency is returned by snd_pcm_delay()
- 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?
Sounds good to me, on first sight.
Hmm, however, there is one thing I'd still need for PulseAudio:
I'd like to know when (in time units) the playback buffer would underrun from now on if I don't write anything anymore. For the USB driver at least this happens much earlier than just calculating (buffer_size - snd_pcm_avail_update()) and transforming that into time units, because the USB driver seems to remove a block at a time from the playback buffer, and hence it will signal the XRUN much earlier then the aforementioned value. To fix this I'd need to know what this granularity is. If I knew that I could fix my sleep time accordingly.
In short: I need some kind of granularity information about snd_pcm_avail_update() but I must admit that right now I am not actually sure which parameter would be the best one to know about.
I think that USB drivers should be fixed using a software FIFO. It means that the ring buffer will be fully maintainable (and underrun occurs correctly then).
It means adding extra URBs to which will be copied data. They will work as "extra" FIFO counted in snd_pcm_delay() but not counted in snd_pcm_avail_update(). If I look to USB code correctly, it's just about to change hw_ptr management. Data are copied to URBs anyway.
Hmm... I don't buy this.
First off, it's not only about USB but for hardwares that require the own h/w queue. There bunch of such hardwares, and we provide really poor support for them. The above sounds like bandaiding on a bandaid over a bandaid.
Well, now I continue to discuss in another post, following Lennart's reply.
Takashi