On 17.06.2015 20:09, David Henningsson wrote: > > > On 2015-06-17 11:19, Takashi Iwai wrote: >> Well, USB-audio has another problem. USB-audio uses the intermediate >> audio ring buffer, and the samples are copied to each URB buffer. At >> each packet complete, the driver copies the rest of sample chunk >> again, and advances the hwptr when the packets. So, the hwptr of >> USB-audio is in advance of the actual sample position. But we provide >> the runtime delay information for user-space to correct to the more >> accurate sample position. So far, so good. >> >> A missing piece in this picture is, however, the position of the >> not-yet-queued samples in ring buffer. Basically you can rewrite / >> rewind the sample at most this point, but not farther -- such >> in-flight samples can't be modified any longer. This can be seen a >> kind of hardware fifo with a pretty big and non-continuously variable >> size during operation. >> >> In that sense, get_fifo() looks like a candidate for giving such >> information, indeed. But reviving the old (and rather bad working) >> API appears dangerous to me. I'd prefer creating a new API function >> instead, if any. >> >> BTW, because of its design like above, a large (or no) period size >> doesn't help for saving power at all with USB-audio. This should be >> considered before the further discussion... > > Hmm...I was trying to understand this power save argument. I tried to > figure out a "typical" URB size by just plugging my headset in, and I > saw wMaxPacketSize being 96 and/or 192 bytes. > Then, MAX_PACKS is set to either 6 (or 48 for USB 2.0 devices, but this > is just a headset). > > Can this be correct? Does it mean that we are getting interrupts every > 192 * 6 bytes (i e, every 6 ms for a 48kHz/stereo/16bit stream)? At least that's how often the position gets updated in the worst case. I have attached a report for a Logitech USB headset and a test program where you can modify the buffer and period sizes. A line is logged every time snd_pcm_avail() returns a different value. -- Alexander E. Patrakov