[alsa-devel] What does snd_pcm_delay() actually return?
tiwai at suse.de
Fri Jun 13 17:42:54 CEST 2008
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
More information about the Alsa-devel