[LAU] Zyn and the art of jack audio/midi

Paul Davis paul at linuxaudiosystems.com
Sat Aug 1 16:12:37 EDT 2009

On Sat, Aug 1, 2009 at 5:04 AM, cal<cal at 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'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" ?

More information about the Linux-audio-user mailing list