(General ramble about matters related to this subject.) Linux is certainly not a realtime OS - but it's a very common misconception that it has anything to do with multithreading. It's just that general purpose (and server) operating systems are optimized for throughput, and there are also reasons you don't even want to make realtime scheduling generally available to applications, even when it's implemented in the kernel.
That said, you can get very close with a "lowlatency" Linux kernel - though, as a former control engineer, I'd still put that firmly in the soft realtime domain. (Pun not intended! I mean, if you can spot it. ;-) That is, sub ms latencies most of the time - but don't bet your house on meeting those deadlines! If you really need rock solid scheduling with sub millisecond deadlines, you can still achieve that "under" Linux, using RT-Linux or RTAI. IRQ and scheduling latencies in the microsecond range. Of course, those solutions pretty much add an extra environment in between Linux and the hardware - but it might be a reasonable alternative to adding custom hardware, especially if you need lots of CPU power within the realtime context. (MCUs and DSPs will never get anywhere near the price/throughput ratio of a workstation or server CPU.) As to MIDI, my instinctive reaction is just, why even bother? 31250 bps. (Unless we're talking "high speed" MIDI-over-USB or something.) No timestamps. You're not going to get better than ms level accuracy with that, no matter what. All you can hope to there, even with custom hardware, is avoid to make it even worse. BTW, I believe there already are MIDI interfaces with hardware timestamping. MOTU Timepiece...? Finally, how accurate timing does one really need? Well, I've written a synth/audio engine that supports realtime scripting with subsample accurate timing. (The VM runs inline with the audio code.) Originally, I just wanted to see if I could hack a "real" synth in less than 2kLOC - so I had to find a way of eliminating all the LFOs, EGs and similar hardwired features, and offer flexibility by other means. The result is that you can script all those things, and even generate custom waveforms on the fly. However, unless you're going to actually work with sound on that low level, I suspect even sample accurate timing is massive overkill. Things quickly get complicated, inefficient, and/or hard to optimize (loop unrolling, SIMD, buffer alignment etc...), so "(sub)sample accurate timing" is perhaps not a requirement you should just throw in there because it sounds cool - unless it demonstrably sounds cool, literally. :-) -- //David Olofson - Consultant, Developer, Artist, Open Source Advocate _______________________________________________ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
