[LAD] jack_midi in jackd and jackdmp

Fons Adriaensen fons at kokkinizita.net
Fri Apr 3 18:15:48 UTC 2009


On Fri, Apr 03, 2009 at 12:49:29PM -0500, Gabriel M. Beddingfield wrote:

> 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?
> 
> ...
>
> > Isn't it common open 2 Clients ?
> 
> I don't think so.

I can make sense to do that, but not for the purpose you
explained.

Your process callback is called by a thread created by
the client side of the jack library. You could in theory
change its priority but I don't think you're supposed to
do that. And it would not help - in each jack cycle *all*
process callbacks have to run and to finish in time, if
they don't jack will throw out your client.

In other words you can't delay execution of a callback.

So if you want to delay processing MIDI, the only option
is to copy the MIDI data (via a ringbuffer or a similar
system) to a lower priority thread that you create yourself.
If you do that, you can as well do it in the same client that
handles the audio.

Ciao,

-- 
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.




More information about the Linux-audio-dev mailing list