Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Raymond Yau <superquad.vortex2@gmail.com>]

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

Do this mean .period_bytes_min of snd-usb-audio is incorrect since
.period_bytes_min should be at least size of urb/packet ?