-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkwb8JgACgkQZbZrB6HelLKXxACfXMVLP9KDqqp+kdp5GXwZwAAP 1qQAoPy3ZX3inZsXIoDec6NR+NYrQ2GQ =34JL -----END PGP SIGNATURE----- _______________________________________________ 64studio-users mailing list [email protected] http://lists.64studio.com/mailman/listinfo/64studio-users
