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@xxxxxxxx) 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: > > > > > > 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? > > > > 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
