[alsa-devel] What does snd_pcm_delay() actually return?
tiwai at suse.de
Fri Jun 13 20:46:12 CEST 2008
At Fri, 13 Jun 2008 20:29:53 +0200,
Lennart Poettering wrote:
> On Fri, 13.06.08 18:26, Takashi Iwai (tiwai at suse.de) wrote:
> > Wait, wait. Please don't mix up. The above doesn't imply anything
> > about the further implementation of usb-audio driver. What I
> > suggested is, instead of hiding two pointers (hw_ptr and curr_ptr) and
> > creating a complex API, simply expose them.
> > Now, regarding the usb-driver. Honestly, I don't understand what you
> > want to do with an extra URB.
> > As now, usb-audio driver handles as curr_ptr == hw_ptr. But, in
> > reality, curr_ptr = hw_ptr - samples_in_urbs. So, in the case
> > of USB-audio, hw_ptr is ahead of curr_ptr. (And the granularity is
> > samples_in_urbs).
> BTW: what's the relation between periods and URBs on usb-audio right
> now? I mean, the URBs should be exposed as periods to userspace,
> right? But they are not right now, are they? I mean, I can set all
> kinds of strange period settings for my USB device and I am pretty
> sure that this is not reflected in the URB size, or am I wrong?
It's a bit complicated due to the restriction of URB size for
isochronous transfer. The driver tries to adjust the packet size and
number of URBs as much as possible to fit with the requested hw
parameters. But, the requested condition doesn't always fit with the
requirement, then the driver's wakeup time drifts a bit.
Whether the condition perfectly fits isn't exposed to the user-space,
unfortunately. I first tried to make a strict hw_params constraint,
but then no apps ever worked. So, the current code is a compromise:
it accepts as much as possible, but doesn't work accurately if the
condition doesn't fit.
More information about the Alsa-devel