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.
How about the result using multiple of 48 frames as period size since min period size is 48 frames (1 ms) , it seem that your tests are not using the optimal period size