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 <[email protected]> >To: [email protected] >CC: [email protected] >References: <[email protected]> > <20100327164326.gd1...@zita2> > >> Hi Fons :) >> >> [email protected] 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 <[email protected]> >To: Linux Audio Developers <[email protected]> > >> 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 [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
