Re: What does snd_pcm_delay() actually return?

[Lennart Poettering <mznyfn@0pointer.de>]

On Fri, 13.06.08 20:46, Takashi Iwai (tiwai@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?

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4