Paul Davis wrote:
if you can run a USB 1 class compliant audio device on
your linux
system with lower latency than the current minimum so far posted to
this thread, please post with the settings you use and the type of
device.
Class compliance doesn't matter, because it's not possible to have audio
transfers with a timing algorithm that isn't already covered by the USB
audio spec.
What matters are
1) the synchronization type (adaptive, asynchronous, implicit feedback);
2) how many packets per second are transferred.
1) In implicit feedback mode, the playback and capture streams always
run in perfect lockstep (i.e., when the streams are started at the
same time, period interrupts are guaranteed to happen at the same
time). In adaptive or asynchronous mode, there is no such
synchronization, so the corresponding playback and capture periods
might be completed one USB frame earlier or later.
The only devices to use implicit feedback are the Edirol UA-1000/101
and IIRC the Tascam devices handled by the snd-usx2y driver; some
others need it but have not yet proper driver support.
2) USB 1.x devices always use 1000 packets/s; USB 2.0/3.0 devices can
use up to 8000 packets/s, but may use less. The more packets are
used, the more precise the period completion interrupts are.
For devices handled by snd-usb-audio, these can be read from the file
/proc/asound/cardX/streamY, which contains entries like this:
| Interface 1
| Altset 18
| Format: S24_3LE
| Channels: 8
| Endpoint: 1 OUT (ASYNC) <-- sync. type
| Rates: 96000
| Data packet interval: 125 us <-- time per packet
The SB Audigy 2 NX is a USB 2.0 device in asynchronous mode; it uses
8K packets/s for playback and 1K packets/s for capture. Without duplex,
I can get down to 2 x 0.4 ms periods, but this is not quite stable
(jackd -d alsa -P hw:8 -r 96000 -p 37 -n 2). For any device with duplex,
I need at least a 4 ms buffer to start streaming, and that blows up when
an xrun happens.
Regards,
Clemens