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

[Takashi Iwai]

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 at 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:
> > > 
> > > 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