3 Apr
2009
3 Apr
'09
1:56 p.m.
Hi to all
Thats my first post to the dev list, first I wont to say hello, and
sorry for my bad english. I try to do my best to make it readable for
you.
So,. . I try to build a jack_midi output port and I get the stuff
working with jackd(1).
But my test's with jackdmp end up with crash's (segfaults).
I realise that's because the needed buffer recived from
jack_port_get_buffer(midi_output_ports, nframes) is == 0 when I run
jackdmp-1.9.2. jackd gives me a buffer from 480.
I 'am only be able to protect the port for crash's but I can't figure
out what I make wrong.
I try and I try and I try, but I can't get now . . .
It would be realy great if someone from the list here is willing to have
a lock at my source and give me a hint to drive me in the right
direction.
My (uggly) sources are here :
http://apps.sourceforge.net/trac/guitarix/browser/trunk/src/main.cpp
midi_process callback start's at line 233
regards hermann
3 Apr
3 Apr
2:08 p.m.
Le 3 avr. 09 à 17:05, hermann meyer a écrit :
Hi to all
Thats my first post to the dev list, first I wont to say hello, and
sorry for my bad english. I try to do my best to make it readable for
you.
So,. . I try to build a jack_midi output port and I get the stuff
working with jackd(1).
But my test's with jackdmp end up with crash's (segfaults).
I realise that's because the needed buffer recived from
jack_port_get_buffer(midi_output_ports, nframes) is == 0 when I run
jackdmp-1.9.2. jackd gives me a buffer from 480.
I 'am only be able to protect the port for crash's but I can't figure
out what I make wrong.
I try and I try and I try, but I can't get now . . .
It would be realy great if someone from the list here is willing to
have
a lock at my source and give me a hint to drive me in the right
direction.
My (uggly) sources are here :
http://apps.sourceforge.net/trac/guitarix/browser/trunk/src/main.cpp
midi_process callback start's at line 233
regards hermann
Hahah this famous Faust based application..
Why are you opening 2 jack clients? Can you describe what are you
trying to so?
Stephane
2:29 p.m.
Am Freitag, den 03.04.2009, 18:04 +0200 schrieb Stéphane Letz:
Le 3 avr. 09 à 17:05, hermann meyer a écrit :
Hi Stephane
Nice to hear from you. :)
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.
Isn't it common open 2 Clients ?
hermann
Hi to all
Thats my first post to the dev list, first I wont to say hello, and
sorry for my bad english. I try to do my best to make it readable for
you.
So,. . I try to build a jack_midi output port and I get the stuff
working with jackd(1).
But my test's with jackdmp end up with crash's (segfaults).
I realise that's because the needed buffer recived from
jack_port_get_buffer(midi_output_ports, nframes) is == 0 when I run
jackdmp-1.9.2. jackd gives me a buffer from 480.
I 'am only be able to protect the port for crash's but I can't figure
out what I make wrong.
I try and I try and I try, but I can't get now . . .
It would be realy great if someone from the list here is willing to
have
a lock at my source and give me a hint to drive me in the right
direction.
My (uggly) sources are here :
http://apps.sourceforge.net/trac/guitarix/browser/trunk/src/main.cpp
midi_process callback start's at line 233
regards hermann
Hahah this famous Faust based application..
Why are you opening 2 jack clients? Can you describe what are you
trying to so?
Stephane 
3:49 p.m.
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?
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?
Isn't it common open 2 Clients ?
I don't think so.
--
G a b r i e l M B e d d i n g f i e l d
4:20 p.m.
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 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.
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.
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.
8 Apr
8 Apr
2:24 a.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:
okay, get it
you are absolutly right, do the processing in one client and check for
cpu useage and frame time make more sence and work like I wont to have
it. thanks 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, Isn't it common open 2 Clients ?
I don't think so.
3 Apr
3 Apr
5:28 p.m.
Am Freitag, den 03.04.2009, 12:49 -0500 schrieb Gabriel M. Beddingfield:
regards hermann
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.
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.
5801
days inactive
5806
days old
linux-audio-dev@lists.linuxaudio.org
8 comments
4 participants
participants (4)
-
Fons Adriaensen -
Gabriel M. Beddingfield -
hermann meyer -
Stéphane Letz