[alsa-devel] PulseAudio and SNDRV_PCM_INFO_BATCH

[Raymond Yau]

>>
>>  >>>
>>  >>> The ALSA API requires the driver to provide a cyclic sample buffer
(or
>>  >>> something that behaves like one).
>>  >>>
>>  >>> However, not all hardware works this way.  USB and FireWire require
the
>>  >>> driver to continually queue new packets, whose size and timing are
>>  >>> determined by the bus clock and are not directly related to the ALSA
>>  >>> ring buffer.  These drivers use double buffering; the actual DMA
>> happens
>>  >>> from those packets, not from the ring buffer.
>>  >>>
>>  >>
>>  >> If those queued packets/urb cannot be rewind, snd_pcm_rewindable
should
>>  >> return zero for those driver
>>  >
>>  >
>>  > Not really.
>>  >
>>  > As I understand it, the kernel periodically converts a piece of the
>> ring buffer (located in RAM) into an URB, and it gets sent through the
>> USB bus. Parts of the buffer that are not yet converted to URB are
>> perfectly rewindable.
>>  >
>>  > In other words, for USB devices, the kernel already implements the
>> "low-latency background thread that makes unrewindable devices
>> rewindable" idea that I discussed (as a strawman proposal) here for
>> userspace:
>>  >
>>  >
>>
http://mailman.alsa-project.org/pipermail/alsa-devel/2014-September/080868.html
>>  >
>>
>> This mean that SNDRV_PCM_INFO_BATCH represent exact one period is not
>> correct for usb and firewire since hw_ptr does not increment in period
size
>
>
> Well, according to the new definition, "SNDRV_PCM_INFO_BATCH on the other
hand has become to mean that the device is only capable of reporting the
audio pointer with a coarse granularity". In the USB case, we indeed have
coarse granularity (6 ms in the worst case), but not as bad as one period.
>
>
>>
>> Do this mean .period_bytes_min of snd-usb-audio is incorrect since
>> .period_bytes_min should be at least size of urb/packet ?
>>
>
> I don't see anything wrong here. With the USB device that my colleague
has here at work, the minimum period size is 48 samples, i.e. 1 ms, which
looks exactly like one USB data packet.
>

What is the smallest buffer time which your usb audio can playback without
underrun using aplay with two periods (2ms or 12ms) ?