[LAD] on the soft synth midi jitters ...
lad at bzzt.net
Tue Oct 5 07:51:35 UTC 2010
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
> 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
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.
More information about the Linux-audio-dev