11 Sep
2003
11 Sep
'03
6:01 a.m.
Hello,
is there anyone with a version of the LL-patch for SuSE kernels?
(I use 8.2 with 2.4.20). Some hunks of the patch are always in
the SuSE kernel (sometimes with small changes as other variable
names) -- and this lead me to think that the SuSE kernels had
included the LL-patch.
Maybe (having the KEYBOARDS discussion in mind) it would be "a
nice thing" if SuSE (and other distributors) have a LL-kernel
ready to run.
Uwe
--
voiceINTERconnect www.voiceinterconnect.de
... smart speech applications from germany
12 Sep
12 Sep
2:50 p.m.
At Thu, 11 Sep 2003 09:46:36 +0200,
Uwe Koloska wrote:
Hello,
is there anyone with a version of the LL-patch for SuSE kernels?
(I use 8.2 with 2.4.20). Some hunks of the patch are always in
the SuSE kernel (sometimes with small changes as other variable
names) -- and this lead me to think that the SuSE kernels had
included the LL-patch.
yes, suse kernel (since 8.1) already includes most of the necessary
changes. some parts are missing but they are on the rare code path,
which has been not audited quite well, anyway.
Maybe (having the KEYBOARDS discussion in mind) it would be "a
nice thing" if SuSE (and other distributors) have a LL-kernel
ready to run.
the LL patch is a easy change.
but it's pretty difficult to apply the preempt patch on the heavily
modified kernel like suse's and redhat's.
if you really need PE, try 2.6 kernel. it's better maintained.
Takashi
15 Sep
15 Sep
7:19 a.m.
Hello,
Takashi Iwai wrote:
yes, suse kernel (since 8.1) already includes most of the
necessary changes. some parts are missing but they are on
the rare code path, which has been not audited quite well,
anyway.
What does this mean?
- If I need low latency, I can use a SuSE kernel without
recompiling it? And don't have to bother about switching LL on
and off? (There is neither the kernel-config option "Low
Latency" nor somethin in /proc to switch it on)
- I can use the SuSE sources, but have to recompile? (with what
options?)
the LL patch is a easy change. but it's pretty
difficult to
apply the preempt patch on the heavily modified kernel like
suse's and redhat's.
if you really need PE, try 2.6 kernel. it's better
maintained.
What do I need the PE patch for?
I am still working at an answer to KEYBOARDS and will detail in
a later letter. For now only some questions:
- (like said above) to get low-latency on a stock SuSE 8.2, I
don't have to bother with the kernel and any configuration
(setting something in /proc) -- right?
- what is the reason for starting the init without full
capabilities? (to use jackstart, I have to rebuild the kernel
with all capabilities set for init -- but this was straightforward)
- when running jackd (from the very nice qjackctl with
jackstart) together with ardour and jamin, I get a number of
xruns. The same configuration under windowmaker doesn't seem to
have this problems. (I am trying to move my CD-mastering from
MacOS-X and Spark LE to Linux)
- the first thing to start with "real" audio under KDE is to
deactivate aRts -- right?
Uwe
--
voiceINTERconnect www.voiceinterconnect.de
... smart speech applications from germany
8:21 a.m.
At Mon, 15 Sep 2003 11:04:05 +0200,
Uwe Koloska wrote:
the preemptive patch will give you much better realtime reponse than
alone with LL patch. but this requires the fundamental change, and
cannot be applied to suse or redhat kernel easily.
as written above, the PE patch was merged to 2.6 kernel.
Hello,
Takashi Iwai wrote:
yes.
yes, suse kernel (since 8.1) already includes most of the
necessary changes. some parts are missing but they are on
the rare code path, which has been not audited quite well,
anyway.
What does this mean?
- If I need low latency, I can use a SuSE kernel without
recompiling it? And don't have to bother about switching LL on
and off? (There is neither the kernel-config option "Low
Latency" nor somethin in /proc to switch it on)
the additional LL stuffs are built in.
there is no sysctl for that.
- I can use the SuSE sources, but have to recompile?
(with what
options?)
no.
the LL patch
is a easy change. but it's pretty difficult to
apply the preempt patch on the heavily modified kernel like
suse's and redhat's.
if you really need PE, try 2.6 kernel. it's better
maintained.
What do I need the PE patch for? I am still working at an answer to KEYBOARDS and will
detail in
a later letter. For now only some questions:
- (like said above) to get low-latency on a stock SuSE 8.2, I
don't have to bother with the kernel and any configuration
(setting something in /proc) -- right?
yes.
- what is the reason for starting the init without
full
capabilities? (to use jackstart, I have to rebuild the kernel
with all capabilities set for init -- but this was straightforward)
it's a question of security.
in fact, the full capability is dangerous from this perspective.
some of last security holes on 2.4 kernel are related with this.
well, in theory, it's possible to enable all capabilities but drop it
in the early boot stage by setting via /proc/sys/cap-bound. but it
will be unlikely implemneted.
it must be pretty hard to convince security guys to accept CAP_SETPCAP
capability as default.
- when running jackd (from the very nice qjackctl with
jackstart) together with ardour and jamin, I get a number of
xruns. The same configuration under windowmaker doesn't seem to
have this problems. (I am trying to move my CD-mastering from
MacOS-X and Spark LE to Linux)
sorry, i don't know jamin.
- the first thing to start with "real" audio
under KDE is to
deactivate aRts -- right?
yes, if it's conflict.
the sb live, for example, can run jackd and artsd for the playback
stream (i.e. not for the full-duplex).
Takashi
9:20 a.m.
Takashi Iwai wrote:
Is there another (secure) way of using jackd in realtime without
making it suid root?
What advice can I give to an unexperienced linux user?
It's a matter of hardware then? Till now I am bound to use the
builtin audio from my ASUS A7N8X Deluxe. But that's not as bad.
For live recording I'm using a iBook with TC.works Spark LE
and Tascam US-122 as audio interface. Then import the session
into ardour and find out what next ;-)))
Uwe
--
voiceINTERconnect www.voiceinterconnect.de
... smart speech applications from germany
- what is the reason for starting the init without full
capabilities? (to use jackstart, I have to rebuild the kernel
with all capabilities set for init -- but this was straightforward)
it's a question of security.
in fact, the full capability is dangerous from this perspective.
some of last security holes on 2.4 kernel are related with this.
well, in theory, it's possible to enable all capabilities but drop it
in the early boot stage by setting via /proc/sys/cap-bound. but it
will be unlikely implemneted.
it must be pretty hard to convince security guys to accept CAP_SETPCAP
capability as default. sorry, i don't know jamin.
very nice mastering jack application -- you must know ;-)
http://jamin.sourceforge.net/
- the first thing to start with "real"
audio under KDE is to
deactivate aRts -- right?
yes, if it's conflict.
the sb live, for example, can run jackd and artsd for the playback
stream (i.e. not for the full-duplex). 
10:09 a.m.
Is there another (secure) way of using jackd in
realtime without
making it suid root?
sudo(1) would be the only other option. but capabilities are
definitely more secure than sudo, IMHO.
What advice can I give to an unexperienced linux user?
install RH, then use Planet CCRMA.
--p
10:45 a.m.
At Mon, 15 Sep 2003 13:05:26 +0200,
Uwe Koloska wrote:
Takashi Iwai wrote:
Is there another (secure) way of using jackd in realtime without
making it suid root?
note that you still need some suid-root (e.g. jackstart) even with
capability.
as Paul suggested, sudo is an alternative solution.
it might be more insecure than capability, depending on the
configuration of sudo, though.
(and it can be more secure with a certain configuration.)
- what is the reason for starting the init without full
capabilities? (to use jackstart, I have to rebuild the kernel
with all capabilities set for init -- but this was straightforward)
it's a question of security.
in fact, the full capability is dangerous from this perspective.
some of last security holes on 2.4 kernel are related with this.
well, in theory, it's possible to enable all capabilities but drop it
in the early boot stage by setting via /proc/sys/cap-bound. but it
will be unlikely implemneted.
it must be pretty hard to convince security guys to accept CAP_SETPCAP
capability as default. What advice can I give to an unexperienced linux user?
again, this is a question of security, too.
that is, whether un "unexperieced linux user" takes care of security.
if the security doesn't matter, you can set simply suid-root on
jackd and jack-related softwares.
(of course, it would be better on a machine without LAN for such a
solution.)
well, i'm not a security paranoi... expert, so it's just my $0.02.
Takashi
7736
days inactive
7740
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
3 participants
participants (3)
-
Paul Davis -
Takashi Iwai -
Uwe Koloska