At Fri, 13 Jun 2008 21:01:15 +0200, Lennart Poettering wrote:
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?
It was pretty hard in the current scheme, IIRC. Almost all hw_params setup become "self-inconsistent".
Takashi