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

Lars-Erik Helander 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. 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. 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. Cpu usage seems light enough, and jack audio does seem to be improved. The Alsa audio also seems promising. I'm keen to see someone else's assessment, maybe I'm just kidding myself. And I'm dealing with Linux, so don't expect good things with a Windows build for example. For what it actually adds, the patch is ridiculously huge. One of the very real problems with the zyn code is the complete absence of whitespace and rational indentation. 25 years ago I used to be able to read (and write) code like that, but not any more. Nowadays, I can't even look at code like that without compulsively adjusting the whitespace - one of my many little ocd's :-(. cheers, Cal