> 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.
What is the smallest buffer time which your usb audio can playback without underrun using aplay with two periods (2ms or 12ms) ?
That device is at work, and is not mine. So, the test below has been done
with a different USB device that I have at home, namely, ROTEL RA-1570 integrated amplifier. It has a menu option to select either 1.0 or 2.0 USB audio class, I have set it to 1.0 to match that C-Media device. By default, with large-enough period size, it has avail granularity that jumps between 3 and 4 ms, and delay granularity of 1 ms (even if I select a better period size, like 960 frames).
Seem time diff vary from 2 to 4 ms
Available: 3410, loop iteration: 130983, diff: 4427, timestamp diff: 3000
usec
Available: 3554, loop iteration: 136790, diff: 5807, timestamp diff: 4000
usec
Available: 3698, loop iteration: 139699, diff: 2909, timestamp diff: 2000
usec
Avail diff can be odd number too
Available: 2353, loop iteration: 100900, diff: 4262, timestamp diff: 3010 usec
Available: 2497, loop iteration: 105000, diff: 4100, timestamp diff: 2991
usec
Available: 2641, loop iteration: 109291, diff: 4291, timestamp diff: 2999
usec
Available: 2785, loop iteration: 113714, diff: 4423, timestamp diff: 3000
usec
Available: 2977, loop iteration: 117955, diff: 4241, timestamp diff: 3000
usec
https://bugs.freedesktop.org/show_bug.cgi?id=86262
The driver does not ensure granularity must be less than period size
granularity can be larger than period size
So it is not just coarse but inaccurate
min_period_size: 6 frames, dir: 0 FIFO size is 0 Hardware PCM card 1 'Scarlett 18i8 USB' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S32_LE subformat : STD channels : 8 rate : 48000 exact rate : 48000 (48000/1) msbits : 32 buffer_size : 4096 period_size : 64 period_time : 1333 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 64 period_event : 0 start_threshold : 64 stop_threshold : 4096 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 Playing silence Available: 0, loop iteration: 0, diff: 0, timestamp diff: 3 usec Available: 66, loop iteration: 9066, diff: 9066, timestamp diff: 1395 usec Available: 132, loop iteration: 11289, diff: 2223, timestamp diff: 1622 usec Available: 192, loop iteration: 13351, diff: 2062, timestamp diff: 1625 usec Available: 258, loop iteration: 15600, diff: 2249, timestamp diff: 1625 usec Available: 325, loop iteration: 17822, diff: 2222, timestamp diff: 1625 usec Available: 385, loop iteration: 20092, diff: 2270, timestamp diff: 1626 usec Available: 451, loop iteration: 22045, diff: 1953, timestamp diff: 1625 usec Available: 512, loop iteration: 24239, diff: 2194, timestamp diff: 1630 usec Available: 578, loop iteration: 26305, diff: 2066, timestamp diff: 1619 usec Available: 644, loop iteration: 28447, diff: 2142, timestamp diff: 1626 usec