1 Jul
2010
1 Jul
'10
8:22 a.m.
On Wed, 2010-06-30 at 14:27 +0200, Adrian Knoth wrote:
On Tue, Jun 29, 2010 at 06:20:30PM -0700, Niels Mayer
wrote:
I'll test PCI as soon as possible too.
Btw. while ports from other computers and my whole MIDI hardware is able
to use my 80ies self-made MIDI thru box, the level of the USB MIDI's
output is to weak to do it (I didn't re-adjust the thru box). Could it
be, that a weak level has impact to the interpretation of the slew rate,
regarding to high and low? Of course without using this box, because it
won't work, I'm thinking of connecting the IOs of the USB MIDI and
running the ALSA latency test.
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.
adi@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).