>What I found quite astounding is how brave pmidi keeps its timing: It >uses no extra threads, no RTC, no suid-root privileges (and my kernel >doesn't have LL or PE patches built in right now), but still plays back >a 10-track MIDI file very time-stable even if I do something like "start >Gimp, Mozilla and Netscape in parallel and switch from the X11 tty to a >text console and back at the same time" (I want to do some more stress >tests here). I guess this shows the power behind ALSA and what correct >ALSA programming can do. It goes without saying that during a playback >of a MIDI file with pmidi the system load produced by it was pretty much >0. Impressive.
its not pmidi thats impressive here. its the ALSA sequencer, which runs in kernel space (for now), effectively as root, and can optionally use the RTC for *better* timing resolution (limited to 10msecs otherwise). what you are not understanding (apparently) is that pmidi dumps the contents of the MIDI file *ahead of time* to the ALSA sequencer, and leaves the scheduling of data delivery to the sequencer. any program that does this will get the same performance as pmidi does. the problem is that if you have a program where the MIDI data to be delivered at time N is not known until time N, then you cannot benefit from the scheduling performance of the ALSA sequencer. i don't know enough about MusE's internals to know if this is actually the case, but i can easily imagine that it could be. my program softwerk is a clear cut example of one where this true - we do not know until the very instant that we are due to deliver MIDI data to the MIDI port just what that data is, and thus the ALSA sequencer (or any other sequencer) is useless as a scheduler. --p _______________________________________________ Alsa-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-user
