8 Apr
2005
8 Apr
'05
7:14 p.m.
hi all ...
another jack newbie question ...
sometimes jacks kicks out my application, since the subgraph times out
...
basically i have two questions about that:
- is there an api function, that tells jack not to kick the application
or a callback that tells the application that it has been kicked out?
- is it possible to query the time out so that i can adapt the callback
that it finished before this time out?
thanks ... tim
--
mailto:TimBlechmann@gmx.de ICQ: 96771783
http://www.mokabar.tk
latest mp3: kMW.mp3
http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone
http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space
would say "I want to see the manager."
William S. Burroughs
8 Apr
8 Apr
7:35 p.m.
On Fri, 8 Apr 2005 23:15:31 +0200
Tim Blechmann <TimBlechmann(a)gmx.net> wrote:
hi all ...
another jack newbie question ...
sometimes jacks kicks out my application, since the subgraph times out
Assuming that other jack clients work without problems, then this
problem description really means (with a pretty high probability) that
your app is violating the RT constraints jack imposes on its clients..
Namely to return as fast as possible from and never ever block in the
process callback.
"Never ever block" pretty much means that you are not allowed to do
anything besides some calculations and usage of lock free datastructures
for communication with your other threads :)
Does your app meet this requirements? Among the definitive nono's are:
- mutex locking (trying it is ok i _think_) or any other synchronisation
mechanisms which might be contended..
- sleeping
- filesystem access
- network access
- UI (be it writing to the console or driving a GUI)
The list surely goes on and on..
...
basically i have two questions about that:
- is there an api function, that tells jack not to kick the application
or a callback that tells the application that it has been kicked out?
As a workaround (dirty) you can tell jack to use a longer timeout (see
the manpage or the qjackctl setup dialog)..
- is it possible to query the time out so that i can adapt the callback
that it finished before this time out?
If your periodsize is 1024 frames at a samplerate of 48000hz, then your
process callback (if it's the only client) needs to finish in less time
than ((1024/48000) - overhead) seconds. Otherwise you'll get an xrun,
which is almost just as bad as a timeout..
Flo
--
Palimm Palimm!
http://affenbande.org/~tapas/
8:16 p.m.
- is there an api function, that tells jack not to kick
the application
absolutely not. if you miss RT deadlines for your process() callback
(or more precisely, if JACK believes you did) it has no choice but to
evict you from the graph. if you are left in the graph, the chances
are that you will just do it again. the only except is if the user
specified on the command line that they did not want this behaviour
(e.g. for live work where an xrun is better than a client being
kicked). but its definitely not up to the client.
or a callback that tells the application that it has
been kicked out?
register a shutdown callback, and you'll find out about it.
- is it possible to query the time out so that i can
adapt the callback
that it finished before this time out?
you know how many frames you have to process and you know the sample
rate. but you have no idea how many other clients are running, so you
don't know how much time *you* actually have. you just have to adhere
to the basic rule:
number of cycles = (A * number of frames) + C
where A and C are constant.
--p
9 Apr
9 Apr
12:09 a.m.
On Sat, 2005-04-09 at 03:02 +0200, Christoph Eckert wrote:
That would not help anything. Why not just fix your client so JACK
doesn't kick it out?
Lee
(e.g. for live
work where an xrun is better than a client
being kicked). but its definitely not up to the client.
would it be possible that the client automatically tries to
reconnect as soon as it was disconnected? Maybe 1 second
later?
12:13 a.m.
would it be possible that the client automatically
tries to
reconnect as soon as it was disconnected? Maybe 1 second
later?
sure. xmms-jack does this. or something like it. but i don't that
think that this is what tim meant. remember, if you overrun RT
deadlines, something is probably wrong. reconnecting won't fix
it. probably.
--p
12:43 a.m.
On Fri, 2005-04-08 at 22:17 -0400, Paul Davis wrote:
If you can't figure out what's causing JACK to kick you out, use a
recent 2.6 kernel with Ingo's RT preempt patches, use a recent JACK from
CVS and build jackd with the --enable-preemption-check option. If your
app does any of the non-RT safe things that Florian referred to, you'll
get a stack trace in dmesg.
Bugs in several JACK clients (like hydrogen) have been found & fixed
using this mechanism.
Lee
would it be
possible that the client automatically tries to
reconnect as soon as it was disconnected? Maybe 1 second
later?
sure. xmms-jack does this. or something like it. but i don't that
think that this is what tim meant. remember, if you overrun RT
deadlines, something is probably wrong. reconnecting won't fix
it. probably.
7:13 a.m.
- is there an
api function, that tells jack not to kick the
application
absolutely not. if you miss RT deadlines for your process() callback
(or more precisely, if JACK believes you did) it has no choice but to
evict you from the graph. if you are left in the graph, the chances
are that you will just do it again. the only except is if the user
specified on the command line that they did not want this behaviour
(e.g. for live work where an xrun is better than a client being
kicked). but its definitely not up to the client. or a callback
that tells the application that it has been kicked out?
register a shutdown
callback, and you'll find out about it. - is it
possible to query the time out so that i can adapt the
callback that it finished before this time out?
you know how many frames you have to process and you know the sample
rate. but you have no idea how many other clients are running, so you
don't know how much time *you* actually have. you just have to adhere
to the basic rule:
number of cycles = (A * number of frames) + C
where A and C are constant.
7228
days inactive
7229
days old
linux-audio-dev@lists.linuxaudio.org
7 comments
5 participants
participants (5)
-
Christoph Eckert -
Florian Schmidt -
Lee Revell -
Paul Davis -
Tim Blechmann