Re: [LAD] [64studio-users] MIDI jitter

On Thursday 01 July 2010, Ralf Mardorf wrote:
>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:
>> > 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@email-addr-hidden:~$ 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).
>
>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,

Yes, but this is not the cause of the latency you are looking for. And yes,
the current capabilities of the drivers should be brought up to specs to
make sure the data doesn't get a scrambled bit occasionally.

>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.

Which, because there is the 10ms worst case latency of USB inherent in the
standards and connection, will probably show worst cases of at least that.

>_______________________________________________
>Linux-audio-dev mailing list
>Linux-audio-dev@email-addr-hidden
>http://lists.linuxaudio.org/listinfo/linux-audio-dev
>

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Save energy:  Drive a smaller shell.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev