On Tue, Oct 05, 2010 at 03:12:12PM +1100, cal wrote: > I'm writing on behalf of a friend who's having trouble dealing with midi > latency in a soft synth (possibly yoshimi) ...
Latency? Or jitter? > Given a jack period of N frames, the midi latency with the original code > effectively ranges from N frames to 2 * N frames, which I guess qualifies > it as jittery. So far my friend has tried a few things, but there's no > workable solution as yet. Of course how bad this is depends on the value of N, but yeah. > What seemed most promising was to break the audio generation into smaller > blocks, applying pending midi events between blocks. Isn't this what JACK does by choosing a period size? Splitting up the processing withing a period like this seems odd. I'm assuming you're talking about ALSA MIDI, here not JACK MIDI - is that correct? > Sadly, that drags the creation and destruction of note objects into the > realtime jack process callback path. (...) Even with a pool of pre-allocated > note objects, it seems the amount of initialization code per note is still a > real limiting factor on how busy things can get before it all falls apart. Of course allocation is forbidden in the process() callback, so that's off limits anyway. Using pre-allocated notes, it sounds kind of unlikely to me that initializing your note objects is the bottleneck. It seems more likely to me that your way of getting the notes from the MIDI device (again - is this ALSA midi? Can you share code/patches?) is not RT-safe. Have you tried running it with http://repo.or.cz/w/jack_interposer.git ? To 'solve' ALSA MIDI jitter for JACK, you'll have to receive ALSA MIDI messages in a seperate thread, and make sure you apply them at the right position in the process buffer based on a timestamp telling you when exactly the note event was recorded. With JACK MIDI, JACK takes care of the recording MIDI events and timestamping them in a sample-accurate way - all you'll have to do is make sure you do take into account the timestamp to correctly place them in the process buffer. This will only 'solve' jitter though: a latency proportional to the period size is inherent to the way JACK works I'm afraid. Hence the desirability of tuning your system to allow for low period sizes. Regards, Arnout _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
