28 Mar
2012
28 Mar
'12
7:35 p.m.
On Thu, Mar 22, 2012 at 09:03:12AM +0100, Emanuel Rumpf wrote:
Am 21. März 2012 18:28 schrieb Joel Roth
<joelz(a)pobox.com>om>:
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
28 Mar
28 Mar
7:45 p.m.
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
7:47 p.m.
On 03/28/12 10:45, David Robillard wrote:
[...]
gotcha, thanks david. looking at ringbuffer now.
--
Ed Sweeney, http://www.onextent.com, Los Gatos CA
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
7:55 p.m.
On Wed, 2012-03-28 at 10:47 -0700, Ed Sweeney wrote:
On 03/28/12 10:45, David Robillard wrote:
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
[...]
gotcha, thanks david. looking at ringbuffer now. 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.
8:51 p.m.
Am 28. März 2012 19:35 schrieb Ed Sweeney <ed(a)onextent.com>om>:
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…
}}
But don't get lost. The topic is large... ;)
Your code looks very clean.
I like that you are using C.
Emanuel
--
E.R.
4435
days inactive
4435
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
3 participants
participants (3)
-
David Robillard -
Ed Sweeney -
Emanuel Rumpf