[alsa-devel] PulseAudio and SNDRV_PCM_INFO_BATCH

[Raymond Yau]

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