[LAD] JACK session API in Perl, Python, Ruby, and Lua
On Thu, Mar 22, 2012 at 09:03:12AM +0100, Emanuel Rumpf wrote: Am 21. März 2012 18:28 schrieb Joel Roth jo...@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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK session API in Perl, Python, Ruby, and Lua
On Wed, 2012-03-28 at 10:35 -0700, Ed Sweeney wrote: On Thu, Mar 22, 2012 at 09:03:12AM +0100, Emanuel Rumpf wrote: [...] The code uses a mutex_lock in the process callback: _lock(_this_); _this_-nframes = nframes; _unlock(_this_); [...] 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. Block the callback = Cause a dropout Don't do that. The standard solution if you need to process audio with non-realtime-safe code is to ringbuffer the data to/from the process callback. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK session API in Perl, Python, Ruby, and Lua
On 03/28/12 10:45, David Robillard wrote: [...] 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. Block the callback = Cause a dropout Don't do that. The standard solution if you need to process audio with non-realtime-safe code is to ringbuffer the data to/from the process callback. -dr gotcha, thanks david. looking at ringbuffer now. -- Ed Sweeney, http://www.onextent.com, Los Gatos CA ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK session API in Perl, Python, Ruby, and Lua
On Wed, 2012-03-28 at 10:47 -0700, Ed Sweeney wrote: On 03/28/12 10:45, David Robillard wrote: [...] 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. Block the callback = Cause a dropout Don't do that. The standard solution if you need to process audio with non-realtime-safe code is to ringbuffer the data to/from the process callback. gotcha, thanks david. looking at ringbuffer now. You're welcome. The capture_client.c example in jack is sort of what you'd have to do, but only in one direction. Someone else may know of a more directly applicable example... (Though, personally I'd suggest using a semaphore if available instead of a mutex/cond pair; sem_post is the best way to signal from the audio thread and the signal will always get through unlike a trylock. Semaphores are awesome, it's really a shame that most portability libraries (and C++0x) don't include them...) -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK session API in Perl, Python, Ruby, and Lua
Am 28. März 2012 19:35 schrieb Ed Sweeney e...@onextent.com: 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. Thanks for asking back. Note: JacksEventQueue_put() uses malloc() and also a blocking mutex. This has to be modified to be lock-free (non-blocking). But rather use a different, existing, verified data-structure. jack_ringbuffer is a possible option, for IO to/from the callback. more here: [[ http://wiki.linuxaudio.org/wiki/programming_libraries#lockfree_non-blocking_data_structures_-_libraries }} But don't get lost. The topic is large... ;) Your code looks very clean. I like that you are using C. Emanuel -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] JACK session API in Perl, Python, Ruby, and Lua
https://github.com/navicore/Jacks Includes sample code for several languages. Developed by Ed Sweeney -- Joel Roth ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev