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

[Takashi Iwai]

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
> work...
> 
> 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".


Takashi