Paul Davis wrote: >>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.
Huh. It's me again. Same previously said machine configuration, LL RTC 2.4.17 kernel, using latest (ALSA 0.9.10a) drivers and pmidi 1.5.4 (both compiled and installed by hand here). Every MIDI played with pmidi has "eaten" notes, even a very simple MIDI file I wrote to test (one channel, max 3 notes playing simultaneously, long notes). The file scatman.mid has lots of eaten notes. Invoking MusE 0.4.14 without options gives the same behavior. With the -RL things get a lot better, and no notes are eaten at all. Both files play just fine on Windoze with CreativeMumboJumboPlayer, Media Player, Winamp, Cakewalk9, Cubasis VST... If somebody wants, I can send these test files to your appreciation and study. Just send me an e-mail requesting. > 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. So we found the guilty! :) Well, ALSA sequencer is working in a strange way, perhaps. If what you say is true, at least for playback we rely on ALSA sequencer, so if anything plays wrong the ALSA sequencer is somewhat defective. But if it doesn't happen with another sound card, so it's a pecific EMU10K implementation problem. Hmmmm... EMU8K, as an example, works right. SB16 MIDI out (Waveblaster2 daugtherboard) works fine too. > 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. I get no xruns with MusE -RL. I don't know about MusE's internals, but it seems to do a better job than the ALSA sequencer's scheduler when the device is EMU10K. If ALSA sequencer is at kernel level, it should be able to change its priority ro RT, or access the RTC directly, without depending on one's permission to. Well, shots in the dark, anyway. But it's still too complicated to play MIDI files with EMU10K. Now another point: My machine is a 350MHz Pentium II. If this may be the problem (slower machine, bigger latency) why the CPU meter doesn't get any greater than10% when playing (worst case)? Why EMU8K works fine? The same "why" about EMU10K on Windoze or MusE -RL on Linux? Thanks again for your efforts, ALSA and MusE developers. We're getting there. Claudio _______________________________________________ Alsa-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-user
