At Fri, 13 Jun 2008 20:29:53 +0200, Lennart Poettering wrote:
On Fri, 13.06.08 18:26, Takashi Iwai (tiwai@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.
Takashi