[LAD] JACK session API in Perl, Python, Ruby, and Lua

[Ed Sweeney]

On Thu, Mar 22, 2012 at 09:03:12AM +0100, Emanuel Rumpf wrote:
> Am 21. März 2012 18:28 schrieb Joel Roth <joelz at pobox.com>:
> >
> > https://github.com/navicore/Jacks
> >
>
> hm ...
> The code uses a mutex_lock in the process callback:
>
>     _lock(_this_);
>     _this_->nframes = nframes;
>     _unlock(_this_);
>
>
> From the doc of pthread_mutex_lock:  "If the mutex is already locked,
> the calling thread blocks until the mutex becomes available."
>
> A try-lock (pthread_mutex_trylock) may be less likely to disturb jacks
> process flow.
>
> --
> E.R.

Hi folks.  I'm the author, new to the list, new to audio, been on 
vacation but back now and hoping to learn and contribute.  Programming / 
playing with jack has been fun!

Emanuel, thx for the suggestion.  The job of that mutex is to block the 
callback until the user code has run, _trylock wouldn't do that.

It is the same approach jack uses when you call jack_session_reply, an 
event completion token pattern that runs this code from jack engine.c

<code>
static void
do_request (jack_engine_t *engine, jack_request_t *req, int *reply_fd)
{
	/* The request_lock serializes internal requests (from any
	 * thread in the server) with external requests (always from "the"
	 * server thread).
	 */
	pthread_mutex_lock (&engine->request_lock);
</code>

I intend to change to _timed_lock for safety but the mutex is there to 
serialize execution between the callback and the perl/python/ruby/lua 
user code.  Open to different designs but this one lets me expose the 
Jack API to multiple languages with one swig.i file and lets the user 
program in a synchronous style.

The overhead of the context switching and locks is unfortunate.  Works 
fine for me reimplementing the example-clients with 48000 sample rate 
but I'm a n00b and don't know what real processing looks like.

Can anyone point me to a way to stress test?  I'd like to know at what 
point all the overhead of my approach plus the costs of the host lang 
VMs breaks things.

Btw, I'm sure the main value of a pkg like this is the session api and 
not the processing.  If you don't open any ports it won't register the 
process_cb callback with Jack and you won't have the processing costs.

Regarding the build/install, I intend to make the main build system 
generate platform distribution-friendly installable dist files rather 
than the ./configure stuff it uses now.  CPAN-friendly, rubyrock, 
luarock, etc...

Sorry for the long post

-Ed