1 Aug
2009
1 Aug
'09
6:12 p.m.
On Sat, Aug 1, 2009 at 5:04 AM, cal<cal(a)graggrag.com> wrote:
Cool, thanks. As it stands, zyn's jack audio/midi
is somewhat primitive. The
jack process callback works against a horrible, horrible hack in Master.cpp.
Also, the code attempts to piggyback jack midi on top of the audio's process
callback, complete with it's own need for a mutex lock.
on some level, this is correct. JACK MIDI arrives in the same callback
as audio. in this respect, JACK MIDI is entirely different from other
MIDI APIs that deliver MIDI in a way that is dissassociated from audio
i/o.
I've split off the jack midi into a separate
entity, which sets up it own
connection to jack, and thus gets it's own process callback that just deals
with midi.
you've just destroyed the entire goal of JACK MIDI :)
I've seriously reworked the jack audio driver. The
process callback
now directly calls the Master.cpp function formerly known as AudioOut().
I've renamed it MasterAudio(), in line with it's accompanying comment -
"Master audio out (the final sound)".
Having to acquire the master processing lock in order for the callback to
pick up the samples is problematic. Rather than throwing in a ringbuffer,
I'm currently trying a little experiment. The audio callback makes just
three attempts to get a lock using trylock. If it gets it, everything is
fine.
If it doesn't acquire the lock, then it simply feeds jack with the resident
set of samples currently in the buffers. My theory there is that repeating
256 samples might be a softer error than feeding 256 silent samples to jack.
From my observations, it doesn't actually miss the lock all that often.
how often is "not all that often" ?