[LAD] jack_midi in jackd and jackdmp

hermann meyer brummer- at web.de
Fri Apr 3 18:37:29 UTC 2009

Am Freitag, den 03.04.2009, 12:49 -0500 schrieb Gabriel M. Beddingfield:
> On Fri, April 3, 2009 10:38 am, hermann meyer wrote:
> > I open 2 clients because I wont 2 treads and give one (the midi tread) a
> > lower prio with pthread_setschedprio. I first try to open the treads
> > from one client, but I cant figure out how to do, with 2 clients that
> > work fine with jackd.
> > I give the midi tread a lower prio, because at least it is a audio app,
> > so midi is "just a gast". On low level CPU's this protect the DSP for
> > xrun's when the CPU limit is reached.
> Have you run in to problems with a single-client scheme?  Was it giving
> you xruns?  IMHO, this is premature optimization.  Doing two clients and
> synchronizing threads is hard, error-prone work -- why not let JACK do
> that work for you?

This is the way I learn,I experience it a lot. Running the midi part at a 
lower prio helps to save CPU time for audio tread's. The effekt only turn in
 when the CPU is overload, then the audio data flow run first. When everything 
is in normal range, it effect nothing, I meen -20 is higher then every app 
running without a rt acces. I only can figure out how to do that when I open 2 clients.

> Besides, if your goal is to ignore MIDI input when the CPU load gets too
> high, why not do something like:
>     process(){
>         if( ! too_busy_for_midi() ) {
>             // process MIDI
>         }
>         // process AUDIO
>     }
> BTW, I see that your midi_process() is reading from a ringbuffer -- who is
> *writing* to it?
Yes, this is new, I have used jack_midi_event_reserve befor, running it
in the compute_midi() part. I switch to the ringbuffer (thanks to Edward
Tomasz Napierala) because I guess first it is this part witch broke my

It's the  DSP.compute_midi(nframes);

you can found it here :

> > Isn't it common open 2 Clients ?
> I don't think so.

regards  hermann

More information about the Linux-audio-dev mailing list