[LAD] jack_midi in jackd and jackdmp

hermann meyer brummer- at web.de
Fri Apr 3 18:00:11 UTC 2009


Am Freitag, den 03.04.2009, 20:15 +0200 schrieb Fons Adriaensen:
> 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,
> 

Hi to all

Thanks for all sugestions, the point here is that I need to register the
midi_port as first one, then everything work. 

I experience a lot with the priority setting for the midi thread, and in
my experience it work well for me. I can skip the midi data befor I lost
audio data. Also other audio app's running at same time are protectet. I
never recive a bad influence from doing that this way.

The  audio data used in the midi thread are just read by the pitch
tracker, never return audio data back to jack from this thread. I dont
experience a differnt when I put them in the Audio thread, yes I have do
that. But that diddn't help.

Now, it work with jackdmp, great,

So the Question comes in mind, why need I to register the midi port as
first one ? Anyone experience the same behaviour ? Or is it just a
effekt from a hidden bug ? mmm

regards    hermann




More information about the Linux-audio-dev mailing list