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

2012-03-28 Thread 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 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

2012-03-28 Thread David Robillard
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

2012-03-28 Thread Ed Sweeney

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

2012-03-28 Thread David Robillard
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

2012-03-28 Thread Emanuel Rumpf
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

2012-03-21 Thread Joel Roth
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