3 Apr
2009
3 Apr
'09
6:09 p.m.
Am Freitag, den 03.04.2009, 20:37 +0200 schrieb hermann meyer:
Am Freitag, den 03.04.2009, 12:49 -0500 schrieb
Gabriel M. Beddingfield:
regards hermann
I have commit the working code now , thanks to all for your help. :)
On Fri, April 3, 2009 10:38 am, hermann meyer
wrote:
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.
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? 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
app.
It's the DSP.compute_midi(nframes);
you can found it here :
http://apps.sourceforge.net/trac/guitarix/browser/trunk/src/dsp.cpp
Isn't
it common open 2 Clients ?
I don't think so.