[linux-audio-dev] LL-patch for SuSE kernel?

[Takashi Iwai]

At Mon, 15 Sep 2003 11:04:05 +0200,
Uwe Koloska wrote:
> 
> 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?

yes.

> 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?
 
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.


> 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