On Tue, Oct 05, 2010 at 09:51:35AM +0200, Arnout Engelen wrote:
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.
Yes, but it provides a simple way to improve an existing
application using Jack-midi, withour requiring very deep
changes to the audio code to make it fully 'sample accurate'.
You will probably already have something like:
jack_process (nframes)
{
read_jack_midi_data(); // read full buffer, create new notes,
// mark those being released.
synthesize(nframes); // audio processing for current notes
}
The latter call will already accept smaller values of nframes,
so no changes at all should be necessary there.
So the only changes required would be to read_jack_midi_data(),
making it read the next required part of the midi buffer instead
of all of it, and then put a loop around the two calls, dividing
Jack's period into smaller ones.
An occasional non-realtime safe call will do less damage as when
using a real smaller period as its effect is amortised over the
full longer period.
This is how I added Jack-midi support to Aeolus. It has an internal
'period' of 64 frames which really can't be changed without rewriting
all of it. Reading the midi data in slices of 64 frames and alternating
this with the synthesis code provides a jitter of +/- 32 frames, which
is probably OK (at least it is for an organ).
Ciao,
--
FA
There are three of them, and Alleline.