On Thu, Mar 22, 2012 at 09:03:12AM +0100, Emanuel Rumpf wrote:
Am 21. März 2012 18:28 schrieb Joel Roth <[email protected]>:
>
> 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
_______________________________________________
Linux-audio-dev mailing list
[email protected]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
