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)?
The driver can build up a URB containing multiple packets, so the wakeups can be reduced in some level. But, then the hwptr update also suffers, and more badly, the in-flight size also increases -- both are bad for sample mixing, obviously.
http://lxr.free-electrons.com/ident?i=SNDRV_PCM_INFO_BATCH
If info batch represent exact one period,
do you mean snd-intel8x0 is worst or better ?
How about firewire which also use packets ?