On Tue, 9 May 2006 12:43:29 +0200 Werner Schweer <ws@xxxxxx> wrote: > Its not that easy. If you play a software synthesizer, the received midi > events can only be processed on the next JACK cycle. To reduce jitter, all > events in MusE are delayed by two JACK cycles. So the minimum midi latency > is two JACK cycles. Immediate processing of midi events whould mean to align > them to JACK cycle boundaries which is something you do not want. > A musician can easily deal with even huge latencies but not with jitter. Reducing jitter and providing a constant latency is the softsynth's job, Not MusE's [well, MusE should of course introduce as little extra delay as possible to minimize latency and jitter]. MusE should simply send out the MIDI event as soon as it has received it [we do still talk about MIDI _through_ right now, no?]. If MusE actually added another two JACK cycles, the resulting latency would be four JACK cycles as the softsynth would add another two JACK cycles itself. The only case where MusE would have to care about this would be when itself were a softsynth. Or maybe when playing recorded tracks of which one goes to a hw synth outside the computer and the other goes to a softsynth. In this case it would make sense to delay the MIDI stream that goes to the hw synth outside the computer by two JACK periods because that's the delay the softsynth will have, too, resulting in both being again played in sync. Maybe we have a complete misunderstanding here, though. > > Additionally, it seems MusE doesn't use ALSA's timestamps for received > > events but manually looks at the timer when it comes around to reading > > the events. This will somewhat degrade the accuracy of received events. > > yes, thats true, but as the receiving thread runs with RT priorities its > negligible in practice. Flo -- Palimm Palimm! http://tapas.affenbande.org
