[alsa-devel] PulseAudio and SNDRV_PCM_INFO_BATCH

[Alexander E. Patrakov]

22.06.2015 17:34, Raymond Yau wrote:
>
>  >>>
>  >>> 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.

-- 
Alexander E. Patrakov