Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[David Henningsson <david.henningsson@canonical.com>]

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)?


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic