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