3 Apr
2009
3 Apr
'09
4:51 p.m.
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:
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
On Fri, April 3, 2009 10:38 am, hermann meyer
wrote:
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,
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.