On Tue, Jun 29, 2010 at 06:20:30PM -0700, Niels Mayer wrote: > What's interesting to note is that most of the USB MIDI interfaces do > not have consistent latency (Other than the Roland UM2's consistent
Let me just show you the result from my Midisport USB 2x2 (standard edition when it was still produced by midiman, not the anniversary edition): set_realtime_priority(SCHED_FIFO, 20).. done. clock resolution: 0.000000001 s > latency distribution: ... 3.1 - 3.2 ms: 1 # ... 3.9 - 4.0 ms: 1 # 4.0 - 4.1 ms: 9903 ################################################## ... 5.0 - 5.1 ms: 95 # > SUCCESS best latency was 3.13 ms worst latency was 5.00 ms, which is great. This is a vanilla 2.6.34 kernel, no realtime patches, no nothing. a...@hex:~$ cat /proc/asound/timers G0: system timer : 4000.000us (10000000 ticks) P0-0-0: PCM playback 0-0-0 : SLAVE P0-0-1: PCM capture 0-0-1 : SLAVE P0-1-0: PCM playback 0-1-0 : SLAVE P0-1-1: PCM capture 0-1-1 : SLAVE P0-2-1: PCM capture 0-2-1 : SLAVE Not even HR timers. And yes, this is SMP, and yes, I have the "ondemand" cpu governor, that is, the evil frequency scaling and the lot. Put simply, it's a plain Debian unstable system, no latency tuning at all. Ok, 4ms are not strikingly fast, but it's acceptable and shouldn't matter in praxis. Especially I don't see any noteworthy jitter. I'm going to measure the mainline kernels from 2.6.26 to 2.6.34 within the next days to see if this stability can be accounted to the parts of the RT patch that have been integrated into mainline. If this hypothesis is correct, I should see a lot of jitter with older kernels. I'll also try to compare it against an onboard MPU-401, a firewire based device and one or two more USB solutions. Long story short: Seems things are not black (USB) and white (PCI). -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev