14 Sep
2005
14 Sep
'05
3:45 a.m.
2.6.13.1-rt6, rlimits-patched pam and configured thus:
# in /etc/security/limits.conf
* - rt_priority 0
* - nice 0
@audio - rt_priority 50
@audio - nice -10
jack starts happily with realtime enabled, and the xruns are very few.
But no jack application will start, they all give this error:
jack_create_thread: error -1 switching current thread to rt for
inheritance: Unknown error 4294967295
It's like the ol' jack is root apps can't connect days, but I thought
rtlimits was supposed to make it possible for a user to get rt_priority.
Am I missing something?
Ah! It came to me just now - I set the priority field in qjackctl to 0
instead of 1 (where it was) and now jack apps can start. Heads up there.
Maybe applications need a way to recognize what rt_priority level to ask
for based on what jack is running at? On a tangent, how exactly does
that work? Is rt_priority=0 sufficiently prioritized? (because it is the
only thing running realtime)
--
Hans Fugal | If more of us valued food and cheer and
http://hans.fugal.net/ | song above hoarded gold, it would be a
http://gdmxml.fugal.net/ | merrier world.
| -- J.R.R. Tolkien
---------------------------------------------------------------------
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460
14 Sep
14 Sep
10:48 a.m.
On Tue, 2005-09-13 at 23:45 -0600, Hans Fugal wrote:
Ah! It came to me just now - I set the priority field
in qjackctl to 0
instead of 1 (where it was) and now jack apps can start. Heads up there.
Maybe applications need a way to recognize what rt_priority level to ask
for based on what jack is running at? On a tangent, how exactly does
that work? Is rt_priority=0 sufficiently prioritized? (because it is the
only thing running realtime)
i think the problem with zero is that with -R, jackd actually needs 2
(or even 3) priorities:
* watchdog thread
* driver thread
* client threads
since it sets the watchdog to run at the stated priority, the others
need to be below it. hence ... the classic UINT_MAX-1 error. we should
probably add a check for the given priority to make sure this can't
happen. care to submit a patch?
--p
11:34 a.m.
On Wed, 14 Sep 2005 at 08:49 -0400, Paul Davis wrote:
On Tue, 2005-09-13 at 23:45 -0600, Hans Fugal wrote:
So you're saying jackd should run at priority 1 or higher, and we ought
to check for that? I could probably manage such a patch, but running at
priority 1 is what was causing this error for me with jack apps. Is
there a way to match priority from jack apps automatically?
--
Hans Fugal | If more of us valued food and cheer and
http://hans.fugal.net/ | song above hoarded gold, it would be a
http://gdmxml.fugal.net/ | merrier world.
| -- J.R.R. Tolkien
---------------------------------------------------------------------
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460
Ah! It came to me just now - I set the priority
field in qjackctl to 0
instead of 1 (where it was) and now jack apps can start. Heads up there.
Maybe applications need a way to recognize what rt_priority level to ask
for based on what jack is running at? On a tangent, how exactly does
that work? Is rt_priority=0 sufficiently prioritized? (because it is the
only thing running realtime)
i think the problem with zero is that with -R, jackd actually needs 2
(or even 3) priorities:
* watchdog thread
* driver thread
* client threads
since it sets the watchdog to run at the stated priority, the others
need to be below it. hence ... the classic UINT_MAX-1 error. we should
probably add a check for the given priority to make sure this can't
happen. care to submit a patch? 
11:51 a.m.
On Wed, 14 Sep 2005 07:33:58 -0600
Hans Fugal <hans(a)fugal.net> wrote:
So you're saying jackd should run at priority 1 or
higher, and we ought
to check for that? I could probably manage such a patch, but running at
priority 1 is what was causing this error for me with jack apps. Is
there a way to match priority from jack apps automatically?
Hi,
there's no priority 0 for SCHED_FIFO threads AFAIK, thus, as jackd runs
at the prio specified via the comandline, the watchdog at prio +10 and
the clients at prio -1, you effectively get a prio of 0 for the clients
when starting jackd with -P 1. Which doesn't work. So, a checking
whether the argument to -P is >= 2 should be enough. Plus the
documentation might need some updating to document the behaviour. I'll
send in a patch for the Documentation in a little while.
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
11:55 a.m.
On Wed, 14 Sep 2005 at 15:51 +0200, Florian Schmidt wrote:
On Wed, 14 Sep 2005 07:33:58 -0600
Hans Fugal <hans(a)fugal.net> wrote:
Ok, I understand that. So I take it if you set qjackctl priority to 0,
it will not specify it and therefore use the JACK default which is >=2?
I tried setting -P to 2 in qjackctl, and it works fine.
--
Hans Fugal | If more of us valued food and cheer and
http://hans.fugal.net/ | song above hoarded gold, it would be a
http://gdmxml.fugal.net/ | merrier world.
| -- J.R.R. Tolkien
---------------------------------------------------------------------
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460
So you're saying jackd should run at priority
1 or higher, and we ought
to check for that? I could probably manage such a patch, but running at
priority 1 is what was causing this error for me with jack apps. Is
there a way to match priority from jack apps automatically?
Hi,
there's no priority 0 for SCHED_FIFO threads AFAIK, thus, as jackd runs
at the prio specified via the comandline, the watchdog at prio +10 and
the clients at prio -1, you effectively get a prio of 0 for the clients
when starting jackd with -P 1. Which doesn't work. So, a checking
whether the argument to -P is >= 2 should be enough. Plus the
documentation might need some updating to document the behaviour. I'll
send in a patch for the Documentation in a little while.
12:01 p.m.
On Wed, 14 Sep 2005 07:55:16 -0600
Hans Fugal <hans(a)fugal.net> wrote:
I suppose jackd should exit with an error when the prio is undefined. What
BTW: if you run a RP system you usually want the jack threads to be
higher prio than all irq handlers other than the soundcard.
--- jackd.1.in.orig 2005-09-14 15:52:00.000000000 +0200
+++ jackd.1.in 2005-09-14 16:00:58.000000000 +0200
@@ -74,7 +74,7 @@
.TP
\fB\-P, \-\-realtime\-priority \fIint\fR
When running \fB\-\-realtime\fR, set the scheduler priority to
-\fIint\fR.
+\fIint\fR. The valid range of values for this switch is between 2 and 89 (This is due to
the fact that jackd runs its main thread, the watchdog thread and the clients threads at
different priorities). The default value is 10.
.TP
\fB\-\-silent\fR
Silence any output during operation.
--
Palimm Palimm!
http://tapas.affenbande.org
there's no
priority 0 for SCHED_FIFO threads AFAIK, thus, as jackd runs
at the prio specified via the comandline, the watchdog at prio +10 and
the clients at prio -1, you effectively get a prio of 0 for the clients
when starting jackd with -P 1. Which doesn't work. So, a checking
whether the argument to -P is >= 2 should be enough. Plus the
documentation might need some updating to document the behaviour. I'll
send in a patch for the Documentation in a little while.
Ok, I understand that. So I take it if you set qjackctl priority to 0,
it will not specify it and therefore use the JACK default which is >=2?
I tried setting -P to 2 in qjackctl, and it works fine.
12:09 p.m.
On Wed, 14 Sep 2005 16:01:12 +0200
Florian Schmidt <mista.tapas(a)gmx.net> wrote:
Oops, hit send too early. I didn't mean "undefined". I actually meant
"out of range". When the pri is "undefined" as in "not specified
by
user", of course the default should be used.
BTW: i think it would make sense to raise the default prio to 70, which
would make jackd work better out of the box with RP kernels (which make
the prio of the irq handlers all around 50). Only thing left for the
user would then be to raise the soundcard irq handler prio.
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
Ok, I
understand that. So I take it if you set qjackctl priority to 0,
it will not specify it and therefore use the JACK default which is >=2?
I tried setting -P to 2 in qjackctl, and it works fine.
I suppose jackd should exit with an error when the prio is undefined. What
12:16 p.m.
On Wed, 14 Sep 2005 at 16:09 +0200, Florian Schmidt wrote:
On Wed, 14 Sep 2005 16:01:12 +0200
Florian Schmidt <mista.tapas(a)gmx.net> wrote:
Oops, hit send too early. I didn't mean "undefined". I actually meant
"out of range". When the pri is "undefined" as in "not specified
by
user", of course the default should be used.
BTW: i think it would make sense to raise the default prio to 70, which
would make jackd work better out of the box with RP kernels (which make
the prio of the irq handlers all around 50). Only thing left for the
user would then be to raise the soundcard irq handler prio.
That's good to know about, thanks. I googled and found your page
http://tapas.affenbande.org/?page_id=6 which shows me how to set the irq
handler prio, however my soundcard seems to be sharing with my video
card. Do you know a way to set which IRQs are used for devices? I have a
cs46xx card as well.
--
Hans Fugal | If more of us valued food and cheer and
http://hans.fugal.net/ | song above hoarded gold, it would be a
http://gdmxml.fugal.net/ | merrier world.
| -- J.R.R. Tolkien
---------------------------------------------------------------------
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460
Ok, I
understand that. So I take it if you set qjackctl priority to 0,
it will not specify it and therefore use the JACK default which is >=2?
I tried setting -P to 2 in qjackctl, and it works fine.
I suppose jackd should exit with an error when the prio is undefined. What
12:22 p.m.
On Wed, 14 Sep 2005 08:16:26 -0600
Hans Fugal <hans(a)fugal.net> wrote:
That's good to know about, thanks. I googled and
found your page
http://tapas.affenbande.org/?page_id=6 which shows me how to set the irq
handler prio, however my soundcard seems to be sharing with my video
card. Do you know a way to set which IRQs are used for devices? I have a
cs46xx card as well.
AFAIK, this depends on the BIOS on your mainboard. On my mainboard i
only had the option of switching slots around until i found one in which
the soundcard got its own irq. Sometimes the irq line routing is
documented in the mainboard manual, but more often than not it's not.
Beware though that sometimes BIOSes also take the class of the device
into account. So, it's mostly trial and error switching slots.
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
6808
days inactive
6808
days old
linux-audio-dev@lists.linuxaudio.org
8 comments
3 participants
participants (3)
-
Florian Schmidt -
Hans Fugal -
Paul Davis