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

On Saturday 19 June 2010, Ralf Mardorf wrote:
>Hi Gene :)
>
>Gene Heskett wrote:
>> 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.
>
>To bad that there isn't a MPU game port any more on modern boards and
>that e.g. my Terratec EWX 24/96 Envy24's MPU needs opto-couplers for the
>cable, but what ever circuit I build on a brad board, they failed.
>Time to mount my old mobo again and to test the game ports MPU with
>today Linux, resp. to get a service manual for my Terratec.
>
>>> 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@email-addr-hidden-dsl.net>
>>> To: fons@email-addr-hidden
>>> CC: linux-audio-dev@email-addr-hidden
>>> References: <4BADBD42.4030505@email-addr-hidden-dsl.net>
>>> <20100327164326.GD1545@email-addr-hidden>
>>>
>>>> Hi Fons :)
>>>>
>>>> fons@email-addr-hidden 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@email-addr-hidden-dsl.net>
>>> To: Linux Audio Developers <linux-audio-dev@email-addr-hidden>
>>>
>>>> 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.
>
>Of course, the rtai seems not to be made for audio.
>
>>> 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.
>
>If it's just that 20k are reserved and that here aren't any other
>technically issues involved, that shouldn't be a problem. When I used
>the on-board graphics I missed 256 MB and it didn't made a difference,
>when making music. OTOH I don't have a CNC machine and could remove the
>package, but it would be fine to keep it, if I cross a CNC's path, even
>if I guess the CNC machines I saw, were not in the supported list. As I
>said, they do use pic micro controllers.
>
>>> 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.
>
>No Windows! If needed I'll write to your friend and get that Atari-VGA
>interface, get a SMPTE interface again and an anlog audio recorder
>again. I also would change the SCSI hard disk in the Lacom interface,
>it's a 42 MB Seagate, without any free space and it sometimes fails on
>startup. The main problem is, that I don't have the money jet and it's
>not that easy to get the money. Another issue is, that I guess it's time
>to use modern software, because it also comes with some advantages
>compared to 80ies software made for the Atari and to the very old
>hardware. E.g. what would happen if one day a chip in the Steinberg
>dongle should break?
>
I don't even know if my atari setup, still in the boxes, has one of those.
It does have about 75 pounds of docs for musical related things with it
though. Too bad there is a rather big pond between us as I wouldn't mind
carrying it back up the stairs & helping someone load his car up if I could
get my $50 back.

>Cheers!
>
>Ralf
>

-- 
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)
Don't SANFORIZE me!!
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev