At Fri, 13 Jun 2008 21:01:15 +0200, Lennart Poettering wrote: > > On Fri, 13.06.08 20:46, Takashi Iwai (tiwai@xxxxxxx) 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
