31 Mar
2006
31 Mar
'06
2:07 a.m.
Hello list,
I've been going through the options available in qjackctl, and also
the options mentioned here: http://www.djcj.org/LAU/jack/. I've
noticed two options:
soft mode
-a (ASIO support)
What's odd is that neither option is mentioned in the other's doc.
For example, I cannot find a reference to ASIO support in qjackctl.
Likewise, I cannot find an explanation for soft mode in jack's doc.
Two questions: what is soft mode, and is ASIO support still supplied
and useful? One additional question: is there a place that provides
comprehensive explanation of jack's features and how to use them?
--
Josh Lawrence
http://www.hardbop200.com
31 Mar
31 Mar
2:14 a.m.
On 3/30/06, Josh Lawrence <hardbop200(a)gmail.com> wrote:
Two questions: what is soft mode, and is ASIO support
still supplied
and useful? One additional question: is there a place that provides
comprehensive explanation of jack's features and how to use them?
From "man jackd"...
-s, --softmode
Ignore xruns reported by the ALSA driver. This makes JACK less
likely to disconnect unresponsive ports when running without
--realtime.
ASIO mode is no longer supported (or documented).
While the jackd man page is relatively complete, patches to clarify or
improve it are always welcome.
--
joq
1 Apr
1 Apr
5:03 a.m.
Jack O'Quin wrote:
On 3/30/06, Josh Lawrence <hardbop200(a)gmail.com>
wrote:
So, to be clear, this means that softmode and realtime are effectively
mutually exclusive?
-Eric Rz.
Two questions: what is soft mode, and is ASIO
support still supplied
and useful? One additional question: is there a place that provides
comprehensive explanation of jack's features and how to use them?
From "man jackd"...
-s, --softmode
Ignore xruns reported by the ALSA driver. This makes JACK less
likely to disconnect unresponsive ports when running without
--realtime. 
7:34 a.m.
On Sat, 2006-04-01 at 03:02 -0500, Eric Dantan Rzewnicki wrote:
In practice yes. There is no point in running both in softmode and
realtime. The worst case scenario is that a client gets deadlocked
within the process() thread and takes over jackd (in the absolutely
worst case, the whole computer) as the jack watchdog thread doesn't kill
the client.
--
Sampo Savolainen <v2(a)iki.fi>
-s,
--softmode
Ignore xruns reported by the ALSA driver. This makes JACK less
likely to disconnect unresponsive ports when running without
--realtime.
So, to be clear, this means that softmode and realtime are effectively
mutually exclusive? 
9:08 a.m.
On Sat, 2006-04-01 at 13:33 +0300, Sampo Savolainen wrote:
On Sat, 2006-04-01 at 03:02 -0500, Eric Dantan
Rzewnicki wrote:
In practice yes. There is no point in running both in softmode and
realtime. The worst case scenario is that a client gets deadlocked
within the process() thread and takes over jackd (in the absolutely
worst case, the whole computer) as the jack watchdog thread doesn't kill
the client.
actually, this is the opposite of the intent.
softmode is there mostly for people who want to use JACK in, for
example, live situations where the occasional xrun is not a disaster.
they want realtime latency settings, but don't want any clients kicked
out if there is an xrun. if the watchdog doesn't work in softmode, its a
bug.
--p
-s,
--softmode
Ignore xruns reported by the ALSA driver. This makes JACK less
likely to disconnect unresponsive ports when running without
--realtime.
So, to be clear, this means that softmode and realtime are effectively
mutually exclusive?
3:27 p.m.
Paul Davis wrote:
On Sat, 2006-04-01 at 13:33 +0300, Sampo Savolainen
wrote:
Thanks Paul. This is what I was hoping to hear. At RFA they probably
don't want Rivendell's caed (core audio engine daemon) getting kicked
out by jack in the middle of a broadcast.
-Eric Rz.
On Sat, 2006-04-01 at 03:02 -0500, Eric Dantan
Rzewnicki wrote:
In practice yes. There is no point in running both in softmode
and
realtime. The worst case scenario is that a client gets deadlocked
within the process() thread and takes over jackd (in the absolutely
worst case, the whole computer) as the jack watchdog thread doesn't kill
the client.
actually, this is the opposite of the intent.
softmode is there mostly for people who want to use JACK in, for
example, live situations where the occasional xrun is not a disaster.
they want realtime latency settings, but don't want any clients kicked
out if there is an xrun. if the watchdog doesn't work in softmode, its a
bug. -s,
--softmode
Ignore xruns reported by the ALSA driver. This makes JACK less
likely to disconnect unresponsive ports when running without
--realtime.
So, to be clear, this means that softmode and realtime are
effectively
mutually exclusive? 
3:49 p.m.
On Sat, 2006-04-01 at 13:27 -0500, Eric Dantan Rzewnicki wrote:
Thanks Paul. This is what I was hoping to hear. At RFA
they probably
don't want Rivendell's caed (core audio engine daemon) getting kicked
out by jack in the middle of a broadcast.
Soft mode is an OK workaround, but you should still try to get the
bug(s) in Rivendell fixed that are causing JACK to kick it out.
Lee
2 Apr
2 Apr
2:21 p.m.
On 1 Apr 2006, at 19:49, Lee Revell wrote:
On Sat, 2006-04-01 at 13:27 -0500, Eric Dantan
Rzewnicki wrote:
There are caed bugs causing this! Please tell!
As far as I can see the process callback is completely lock free, if
not I want to know...
Now if you are setting soft mode for insurance that is another thing,
but please report any instances of caed getting kicked by jack (I have
never seen it happen).
CCed to rivendell-prog
Regards, Dan.
Thanks Paul. This is what I was hoping to hear.
At RFA they probably
don't want Rivendell's caed (core audio engine daemon) getting kicked
out by jack in the middle of a broadcast.
Soft mode is an OK workaround, but you should still try to get the
bug(s) in Rivendell fixed that are causing JACK to kick it out.
2:42 p.m.
On Sun, 2006-04-02 at 17:21 +0100, Dan Mills wrote:
On 1 Apr 2006, at 19:49, Lee Revell wrote:
Yes - JACK will only kicks out clients that take too long in the
process() callback. Kernel induced xruns will not cause clients to be
disconnected.
If you build JACK with the preemption check option and use an -rt kernel
with the debug options enabled you may be able to get a stack trace if
the app blocks in the process() callback, but it won't help to debug a
client that simply takes too long.
On Sat, 2006-04-01 at 13:27 -0500, Eric Dantan
Rzewnicki wrote:
There are caed bugs causing this! Please tell!
Thanks Paul. This is what I was hoping to hear.
At RFA they probably
don't want Rivendell's caed (core audio engine daemon) getting kicked
out by jack in the middle of a broadcast.
Soft mode is an OK workaround, but you should still try to get the
bug(s) in Rivendell fixed that are causing JACK to kick it out. As far as I can see the process callback is completely
lock free, if
not I want to know...
Now if you are setting soft mode for insurance that is another thing,
but please report any instances of caed getting kicked by jack (I have
never seen it happen).
CCed to rivendell-prog
Regards, Dan.
2:52 p.m.
On 2 Apr 2006, at 17:42, Lee Revell wrote:
On Sun, 2006-04-02 at 17:21 +0100, Dan Mills wrote:
The thing is, the RT thread is just not that CPU intensive, all the
heavy lifting
is done in the disk butler thread and the communication is via lock
free ring
buffers and volatile flags.
CAED should NOT be doing this!
Now it is possible for the disk (or network IO to under run in which
case the audio
breaks up, but that does not impact the process callaback.
Eric, can we have a way to reproduce please, this needs sorting.
Regards, Dan.
On 1 Apr 2006, at 19:49, Lee Revell wrote:
Yes - JACK will only kicks out clients that take too long in the
process() callback. Kernel induced xruns will not cause clients to be
disconnected.
If you build JACK with the preemption check option and use an -rt
kernel
with the debug options enabled you may be able to get a stack trace if
the app blocks in the process() callback, but it won't help to debug a
client that simply takes too long. On Sat, 2006-04-01 at 13:27 -0500, Eric Dantan
Rzewnicki wrote:
There are caed bugs causing this! Please tell!
Thanks Paul. This is what I was hoping to hear.
At RFA they
probably
don't want Rivendell's caed (core audio engine daemon) getting
kicked
out by jack in the middle of a broadcast.
Soft mode is an OK workaround, but you should still try to get the
bug(s) in Rivendell fixed that are causing JACK to kick it out.
3 Apr
3 Apr
12:27 p.m.
Dan Mills wrote:
On 2 Apr 2006, at 17:42, Lee Revell wrote:
it's not.
On Sun, 2006-04-02 at 17:21 +0100, Dan Mills
wrote:
The thing is, the RT thread is just not that
CPU intensive, all the
heavy lifting
is done in the disk butler thread and the communication is via lock
free ring
buffers and volatile flags.
CAED should NOT be doing this! On 1 Apr 2006, at 19:49, Lee Revell wrote:
Yes - JACK will only kicks out clients that take
too long in the
process() callback. Kernel induced xruns will not cause clients to be
disconnected.
If you build JACK with the preemption check option and use an -rt kernel
with the debug options enabled you may be able to get a stack trace if
the app blocks in the process() callback, but it won't help to debug a
client that simply takes too long. On Sat, 2006-04-01 at 13:27 -0500, Eric Dantan
Rzewnicki wrote:
> Thanks Paul. This is what I was hoping to hear. At RFA they probably
> don't want Rivendell's caed (core audio engine daemon) getting kicked
> out by jack in the middle of a broadcast.
Soft mode is an OK workaround, but you should still try to get the
bug(s) in Rivendell fixed that are causing JACK to kick it out.
There are caed
bugs causing this! Please tell! Now it is possible for the disk (or network IO to
under run in which
case the audio
breaks up, but that does not impact the process callaback.
Eric, can we have a way to reproduce please, this needs sorting.
patch -p1 < erics_braindead_patch
There is nothing to worry about. The question just came to mind because
I had managed to screw caed up enough to get it kicked out, so it
occured to me that we might want to consider softmode just for
insurance. Again, as far as I know the distributed caed does not have a
realtimeness problem.
mea culpa.
-ERic Rz.
12:22 p.m.
Dan Mills wrote:
On 1 Apr 2006, at 19:49, Lee Revell wrote:
No, no. Sorry, that was not what I was saying at all. See my other
reply. I just wanted to know as a precaution.
On Sat, 2006-04-01 at 13:27 -0500, Eric Dantan
Rzewnicki wrote:
There are caed
bugs causing this! Please tell! Thanks Paul. This is what I was hoping to hear.
At RFA they probably
don't want Rivendell's caed (core audio engine daemon) getting kicked
out by jack in the middle of a broadcast.
Soft mode is an OK workaround, but you
should still try to get the
bug(s) in Rivendell fixed that are causing JACK to kick it out. As far as I can see the process callback is completely
lock free, if
not I want to know...
Likewise. It's fine. I've just a found a few ways to make it miss the
deadline due to some changes I tried in my own attempts at trying to fix
a different issue.
Now if you are setting soft mode for insurance that is
another thing,
Exactly the intent of my question.
but please report any instances of caed getting kicked
by jack (I have
never seen it happen).
Of course. As said, I haven't seen it happen other than when I changed
something in a stupid way.
Sorry to have caused you stress and alarm, Dan. ;)
-Eric Rz.
12:17 p.m.
Lee Revell wrote:
On Sat, 2006-04-01 at 13:27 -0500, Eric Dantan
Rzewnicki wrote:
There aren't currenlty bugs of that nature, as far as I know. I've never
seen caed get kicked out, except while working on the code trying to fix
other issues.
I'm asking about this just as a precaution.
-ERic Rz.
Thanks Paul. This is what I was hoping to hear. At
RFA they probably
don't want Rivendell's caed (core audio engine daemon) getting kicked
out by jack in the middle of a broadcast.
Soft mode is an OK workaround, but you
should still try to get the
bug(s) in Rivendell fixed that are causing JACK to kick it out.
11:26 a.m.
On 4/1/06, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
actually, this is the opposite of the intent.
softmode is there mostly for people who want to use JACK in, for
example, live situations where the occasional xrun is not a disaster.
they want realtime latency settings, but don't want any clients kicked
out if there is an xrun. if the watchdog doesn't work in softmode, its a
bug.
--p
Wow, this explains a lot for me. I'm trying to use it live, but I
have never checked the softmode options. Many of my apps produce
xruns when they start, and thus the client disconnects. It's good to
know there may be a way to avoid this.
--
Josh Lawrence
http://www.hardbop200.com
11:34 a.m.
On Mon, 2006-04-03 at 08:26 -0500, Josh Lawrence wrote:
On 4/1/06, Paul Davis
<paul(a)linuxaudiosystems.com> wrote:
my description was actually misleading. i apologize for that.
the main point of softmode is to ignore ALSA-reported xruns. it is not
related to client handling. this has often been requested, but its
actually much harder to do than it may appear.
--p
actually, this is the opposite of the intent.
softmode is there mostly for people who want to use JACK in, for
example, live situations where the occasional xrun is not a disaster.
they want realtime latency settings, but don't want any clients kicked
out if there is an xrun. if the watchdog doesn't work in softmode, its a
bug.
--p
Wow, this explains a lot for me. I'm trying to use it live, but I
have never checked the softmode options. Many of my apps produce
xruns when they start, and thus the client disconnects. It's good to
know there may be a way to avoid this.
6810
days inactive
6813
days old
linux-audio-user@lists.linuxaudio.org
14 comments
7 participants
participants (7)
-
Dan Mills -
Eric Dantan Rzewnicki -
Jack O'Quin -
Josh Lawrence -
Lee Revell -
Paul Davis -
Sampo Savolainen