[alsa-devel] What does snd_pcm_delay() actually return?
tiwai at suse.de
Fri Jun 13 21:05:27 CEST 2008
At Fri, 13 Jun 2008 21:01:15 +0200,
Lennart Poettering wrote:
> On Fri, 13.06.08 20:46, Takashi Iwai (tiwai at suse.de) wrote:
> > > > 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.
> Grmbl. I'd strongly prefer if the kernel would give me the data I am
> asking for instead of emulating stuff just to get broken programs to
> Any chance to change this behaviour? Maybe during runtime by setting
> some "I want things raw" flag?
It was pretty hard in the current scheme, IIRC.
Almost all hw_params setup become "self-inconsistent".
More information about the Alsa-devel