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

On Saturday 19 June 2010, Ralf Mardorf wrote:

This will go back only to LAD as I'm not subbed to the others, Ralf.

>Ichthyostega wrote:
>> Ralf Mardorf schrieb:
>>> Another stupid question induced by an argument regarding to MIDI jitter
>>> by Daniel James.
>>>
>>>> [snip] I'm sceptical that the realtime kernel is the cause of your
>>>> MIDI problems. If they got this right in the 80's, on computers which
>>>> could not do anything near realtime audio processing, then I think
>>>> it's more likely to be a question of MIDI application design.
>>
>> At that point we should call back, how that whole story with "realtime"
>> started. At the begining was a design mismatch. Many things related to
>> the Linux kernel started out with a kind of "I feel fine" pragmatism.
>> Which, btw isn't to criticise as it is, because this also accounts
>> for the freshness and sometime unconventional new approach to some
>> problems. But with regards to timings, for all of the first decade
>> of Linux development, there seemed to be a completely different
>> mental model, which we could summarise as: permormance == throughput,
>> and timings are only relevant, when you get a network timeout, or
>> a sluggish response in your application's GUI.
>>
>> Thus, if we now consider to use a Linux kernel for making music, we must
>> assess that the whole design isochronously assumed about 1000 times more
>> headroom as there really is.
>>
>> Thus, as writing a new Kernel doesn't seem to be an option, this whole
>> tedious undertaking of the "realtime patches" can be described as an
>> attempt to fix this "problem" (which was never assumed to be a problem
>> in the initial design) by hunting down one by one each individual
>> instance where the existing kernel could possibly be reacting too slow.
>>
>> Thus, we should rather be surprised, how good these realtime kernels
>> work. OTOH, is isn't a surprise the machines from the 80s meet these
>> criteria; their OS software was written with an awareness for a much
>> more limited processing capability right from start.
>>
>>> Why do people (not only me) report jitter for external MIDI equipment,
>>> but I couldn't find any report for real-time audio jitter? Resp. what's
>>> about async and disconnecting clients by JACK?
>>
>> Audio and MIDI are two quite different beasts.
>> Sound is processed in Blocks, where the individual unity (1 Sample) is
>> much more fine grained and way below anything which can be discerned by
>> a human ear. Moreover, Sound as such already exists and 'just' has to
>> be piped through. To the contrary, MIDI consists of events, which
>> immediately trigger a reaction, which could be that a piece of software
>> and at the same time a piece of external hardware starts a processing
>> cycle. You see, thats a completely different situation and thus it's
>> obvious, why for these two media the same problem causes so different
>> symptoms.
>>
>>> OTOH on Windows audio clients don't disconnect,
>>> just MIDI jitter is an issue too.
>>
>> IIRC, this was a design decision for JACK. It never tries to conceal
>> any timeout problem, rather it requires its clients to keep up with
>> a very tight schedule and comply to very strict rules.
>>
>> I don't know the MIDI part of Jack well enough to judge, if it was
>> designed with the same "you're required to comply" policy. And besides,
>> when the MIDI interface is hooked up via USB, we again face a completely
>> different situation. USB is a complicated protocol, which multiple
>> versions and levels and is certainly not designed to get an individual
>> event transfered reliably with less than 2ms jitter.
>> There is even the possibility that the USB peers negotiate to use a
>> lower transfer rate or protocol version transparently, when they
>> determine the connection can't keep up with the higher speed.
>>
>> Cheers
>> Hermann V.
>
>It's said that USB MIDI interfaces should be the better choice. But this
>explains a lot. Dunno how to read Fons JACK MIDI jitter test, but ...

On the face of it, and reading the USB specs, USB would seem to be a poor
choice for midi unless it re-clocks everything.before sending it out the
MIDI port. Usb has a 10 millisecond worst case lag in the specs.
>
>Subject: Re: [LAD] Again MIDI jitter - tested with Fons test applications
>Date: Sat, 27 Mar 2010 18:26:33 +0100
>From: Ralf Mardorf <ralf.mardorf@alice-dsl.net>
>To: fons@kokkinizita.net
>CC: linux-audio-dev@lists.linuxaudio.org
>References: <4BADBD42.4030505@alice-dsl.net>
> <20100327164326.GD1545@zita2>
>
>> Hi Fons :)
>>
>> fons@kokkinizita.net wrote:
>> > On Sat, Mar 27, 2010 at 09:09:38AM +0100, Ralf Mardorf wrote:
>> >> Regular it shifted between 2395 and 2404, but with a few exceptions,
>> >> one time 2302, three times 2304, two times 2305 and two time 2494.
>> >> See attachment.
>> >> What might cause this exceptions? Could it be access to the RAM by
>> >> the graphics? Is there something bad because of the IRQs?
>> >>
>> >> Regular shift 2404 - 2395 = 9 frames of jitter, exceptional maximal
>> >> shift 2494 - 2302 = 192 frames of jitter.
>> >>
>> >> I guess this does mean ...
>> >> 5.3 ms / 512 frames = 0.010351562 ms/frame
>> >> Maximal difference for regular jitter 0.093164062 ms.
>> >> Maximal difference for exceptional jitter 1.9875 ms.
>> >> ... am I wrong?
>> >
>> > Wrong once or twice, if twice in such a way that the two
>> > errors cancel out.
>> >
>> > First note that the test prints the difference between
>> > events. That means that e.g. if *one* note is 100 samples
>> > late you could see 2400 2500 2300 2400.
>> >
>> > The '2300' is just because the previous one was late,
>> > not because this one arrives too early. So you should
>> > divide the jitter as you measure it by two.
>>
>> Aha, okay this is plausible.
>>
>> > Second, 5.33 ms = 256 frames at 48 kHz. But maybe you
>> > are using 96 kHz ??
>>
>> So you didn't read the attachment ;), yes I did use 96 KHz.
>> [snip]
>
>Subject: Again MIDI jitter - tested with Fons test applications
>Date: Sat, 27 Mar 2010 09:09:38 +0100
>From: Ralf Mardorf <ralf.mardorf@alice-dsl.net>
>To: Linux Audio Developers <linux-audio-dev@lists.linuxaudio.org>
>
>> When I once tested it by recording I got this result for ALSA MIDI on
>>
>> Linux, Cubase runs on Windows on the same machine:
>> ||Cubase|HR tmr|System|PCM pl|PCM ca
>>
>> ------++------+------+------+------+------
>> 500.0 || 493.0| 504.9| 505.6| 503.4| 503.2
>> 1000.0|| 993.4|1005.4|1005.8|1005.3|1006.4
>> 1500.0||1494.5|1503.6|1506.4|1507.4|1507.3
>> 2000.0||1994.8|2003.8|2007.2|2007.9|2009.5
>> 2500.0||2492.4|2504.1|2504.3|2503.6|2503.2
>> 3000.0||2992.9|3006.0|3006.2|3005.9|3007.6
>> 3500.0||3493.7|3502.7|3505.4|3506.5|3509.5
>> 4000.0||3994.6|4003.1|4003.2|4008.8|4009.9
>> msec +/- 0.1 msec
>> maxDif|| 4.8| 6.0| 7.2| 8.8| 9.9
>> minDif|| -2.4| -2.7| -3.2| -3.4| -3.2
>> --------------+------+------+------+------
>> Jitter|| 2.4| 3.3| 4.0| 5.4| 6.7
>> msec +/- 0.2 msec
>
>... as you can see, for Cubase I got this 2ms of jitter. So regarding to
>your explanation Herman, Windows + ASIO + Cubase does a good job, just
>the USB interface will limit it, while for Linux there seems to be
>another issue too, but the USB interface. Btw. Linux HR tmr is a PITA,
>just System, PCM pl and PCM ca are usable without issues for all Linux
> apps.
>
>What could be the cause that Windows just is limited to the USB
>interface by 2.4 ms, but Linux comes with 4.0 ms on my machine?
>
>Joshua Boyd on LAD wrote:
>> On Thu, Jun 17, 2010 at 10:37:25AM -0400, Gene Heskett wrote:
>>>> At my school we transfered the CAD files per floppy to a DOS box that
>>>> controlled the CNC machine, guess that's for the same reason, bad rt
>>>> capabilities of newer OSes and machines.
>>>
>>> The RTAI works pretty well, I can start a job, switch away from that
>>> window, and talk to the guys on IRC, or browse the web without hurting
>>> the job. That to me is true multitasking.
>>
>> So, that leaves me wondering why no one seems to be trying RTAI for
>> audio work? Or is someone doing that and I'm just not aware?
>
>Today I tried to do so.
>
>I tried to run JACK2 with -R switch by user and by sudo, the result was
>the same as here, when I launched JACK2 without -R switch on 64 Studio
>3.0 beta based on Ubuntu Hardy:
>
>$ uname -r
>2.6.24-16-rtai
>
>$ jackd -dalsa -dhw:0 -r96000 -p512 -n2
>jackdmp 1.9.3
>Copyright 2001-2005 Paul Davis and others.
>Copyright 2004-2009 Grame.
>jackdmp comes with ABSOLUTELY NO WARRANTY
>This is free software, and you are welcome to redistribute it
>under certain conditions; see the file COPYING for details
>JACK server starting in non-realtime mode
>creating alsa driver ... hw:0|hw:0|512|2|96000|0|0|nomon|swmeter|-|32bit
>control open "hw:0" (No such file or directory)
>Cannot initialize driver
>no message buffer overruns
>JackServer::Open() failed with -1
>Failed to start server
>
>ALSA seq couldn't start too.

Which could be an interaction with the rtai kernel.

>I run the EMC2 / HAL latency-test:
>
>Servo thread (1.0 ms): max interval 999180 ns, max jitter 10949 ns, last
>interval 992259 ns
>Base thread (25.0 us): max interval 34551 ns, max jitter 9640 ns, last
>interval 24887 ns
>
>The same test couldn't be used for my kernel-rt:
>
>$ uname -r
>2.6.31.12-rt20
>
>$ latency-test

The -rt20 kernel bears little or no resemblance to the rtai version, and
latency-test will not run without its features.

>insmod: can't read '/usr/realtime-2.6.31.12-rt20/modules/rtai_hal.ko':
>No such file or directory
>RTAPI: ERROR: could not open shared memory (errno=2)
>HAL: ERROR: rtapi init failed
>halcmd: hal_init() failed: -9
>NOTE: 'rtapi' kernel module must be loaded
>RTAPI: ERROR: could not open shared memory (errno=2)
>HAL: ERROR: rtapi init failed
>halcmd: hal_init() failed: -9
>NOTE: 'rtapi' kernel module must be loaded
>RTAPI: ERROR: could not open shared memory (errno=2)
>HAL: ERROR: rtapi init failed
>halcmd: hal_init() failed: -9
>NOTE: 'rtapi' kernel module must be loaded
>ERROR: Module hal_lib does not exist in /proc/modules
>ERROR: Module rtapi does not exist in /proc/modules
>ERROR: Module rtai_math does not exist in /proc/modules
>ERROR: Module rtai_sem does not exist in /proc/modules
>ERROR: Module rtai_fifos does not exist in /proc/modules
>/usr/bin/emc_module_helper: Invalid usage with args: remove rtai_ksched
>[snip]
>ERROR: Module rtai_hal does not exist in /proc/modules
>
>Btw. should I commend out the EMC2 memlock when doing audio work again
>or doesn't have it an impact?
>
>$ cat /etc/security/limits.conf | grep memlock
># - memlock - max locked-in-memory address space (KB)
>@audio - memlock unlimited
># @audio - memlock 2000000
>* hard memlock 20480 #EMC2

At only 20k, I doubt it makes much difference, but test anyway.
>
>Cheers!
>
>Ralf
>
>PS: What now? It's my second hardware set up. I just bought a new
>computer a long time ago, because the old computer wasn't ok for Linux
>too, but I don't have the money to pay for one machine after the other,
>until I might have good luck. Both machines are 100% stable for Windows,
>for Linux I also get asyncs + distortion when using JACK2. I didn't test
>if current JACK1 is ok, or if it would disconnect clients. Don't get me
>wrong, I never was a private Windows user, it just were installs for
>testings. I'm using Linux only at home.
>
Being an ardent purist can bite you. As another friend of mine would say,
use what works.

-- 
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)
A program generator creates programs that are more buggy than the program 
generator
		-- Murphy's Laws of Computation n�3
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev