14 Apr
2005
14 Apr
'05
5:43 a.m.
Alfons Adriaensen wrote:
At 48 kHz, USB delivers and consumes audio samples in
chunks of 48 frames.
Depends. This is true for playback (for most devices), but recording
is done with whatever chunk sizes the device delivers. This may be
close to 48 samples per USB frame if the device synchronizes its
internal clock to the USB frame clock.
When using ALSA's mmap inmterface,
... or the read/write interface, there's no difference, ...
these will repackaged to the requested period size.
Yes. The driver will pick a period size that is bigger than one USB
request buffer (URB), and will issue an 'interrupt' whenever a period
has been completely filled.
So one would expect to see a jitter with a range of 1
ms in the
wakeup times of a thread waiting on this interface. For example
for p = 256 the real periods will be 6ms, 5ms, 5ms, 6ms, 5ms, 5ms,
... for an average period of 5.333 ms.
In practice, when using snd-usb-audio, the jitter range is close to 4 ms.
Why is this, and can something be done about it ?
A USB request can be made for more than one USB frame. By default,
the driver uses about four packets per URB which means that the driver
gets notified by the USB controller in 4 ms intervals.
This can be changed with the nrpacks parameter of the snd-usb-audio
module.
Have a look at /proc/asound/cardX/stream0 while running; the numbers
in brackets after "URBs" are the number of packets per URB, which
should be the same as the jitter in ms.
HTH
Clemens