Hi, [EMAIL PROTECTED] wrote:
> > Honestly, I believe I never tried building MusE without ALSA, and I > > believe by now it's impossible to build OSS-only versions of MusE. ALSA > > is the way to go anyway :-}. > > If that ALSA thing only worked... I have a SBLive! Platinum 5.1, using > ALSA 0.9.10a drivers, the low-latency patch from > > http://www.zip.com.au/~akpm/linux/schedlat.html#downloads installed and enabled, and >I have yet to see an ALSA MIDI player that doesn't eat notes when playing using >EMU10K synth. Hmm..well, I once noticed dropped notes with my Emu10k1-based Soundblaster PCI512 as well (most obvious when using pmidi, but it also happened with MusE). I had made some attempts to find out where exactly this note-dropping would happen, but I've never gotten very far. [..] > complaint about a bug and do nothing about, but my programming skills > are directed to a diverse area. Nevertheless, I have a sugestion about it: > Note-eating on EMU10K seems to be a problem caused by a note-on and a > note-off events sent almost the same time due to latency problems, let's > say: I have a 1/32th note to play (very common on drum and "virtuoso" > tracks), but my latency someway makes the note-on and note-off events > associated to this given note to be sent almost together, to accomodate > the MIDI playing to the overall tempo of the MIDI file. It could explain > why I get so many xrun events when playing with MusE and why I can > listen slow tempo files almost without "artifacts" (and why these > artifacts don't occur always at the same place. It changes from program > to program, and even on different places when we run the same program > may times). Ok, so a first thing to find out would be who or what causes these dropouts. You say the Windows drivers have no problems, so it's hopefully no hardware issue - which is good. Now it could still be in either MusE (or whatever MIDI file player you use), alsa-lib or alsa-driver. alsa-lib is directly linked to MusE, so I believe there will not be too much delay between these two. Now I wonder if there is a (moderately) easy way to find out for sure at exactly what times what NoteOn/NoteOff messages get sent from MusE to alsa-lib, from alsa-lib to the kernel-based alsa-driver, and from there to the hardware. I imagine using rdtsc() to read the high-resolution CPU clock and output its value whenever a Note event is to be sent. Within MusE, one might sent the output to a file or e.g. /dev/tty8 through fwrite/write (hopefully not creating too much extra load through this), and for the alsa-driver it would be done with something like printk(). Is this idea reasonable? Could it help in detecting the faulty part? If so, I'll happily try whatever the experts suggest. > I don't know anything about ALSA internals, and my proposition probably > is a shot in the dark, but if it is right, a solution could be to delay > the note-off event to at least the time the note is intended to play, or > God knows what. I'm also no ALSA hacker, but I think artificially delaying events sounds like a bad hack - on some boards you might need it, on others you don't, but generally I cannot imagine this should become necessary once the rest works fine. The only situation I know of where delaying events makes sense is when you are working with lots of tracks in a MIDI sequencer, and some 20 or so notes are supposed to be played simultaneously - in that case, and if you know some of your MIDI devices respond a bit slowly, you would have the sequencer send their respective NoteOn events a little earlier than for the other tracks (I believe VST can do this?) > Thanks to every ALSA developer, and my best wishes I'll someday be able > to play a MIDI file the right way. Same for me - I believe ALSA is a very good thing for the Linux sound community, and the team around Jaroslav, Takashi and the others have done terrific work there. Oh, btw - what about documentation? ;-) Thanks, Frank _______________________________________________ Alsa-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-user
