New Package for Review: jack-audio-connection-kit (&selinux?)

[Fernando Lopez-Lezcano]

On Thu, 2005-03-24 at 14:35, Aaron VanDevender wrote:
> On Thu, 2005-03-24 at 14:02 -0800, Fernando Lopez-Lezcano wrote:
> > For the current working release of the Jack Audio Connection Kit at
> > Planet CCRMA see:
> > http://ccrma.stanford.edu/planetccrma/mirror/all/linux/SRPMS/jack-audio-connection-kit-0.99.36-0.2.cvs.src.rpm
> > 
> > (this cvs release has some fixes that enables it to work better with
> > 2.6.x and the lsm realtime kernel module, more below on this - I was
> > meaning to submit it but was waiting for legal stuff here at Stanford
> > before doing that so that I could be its maintainer, sigh, it is a
> > prerequisite to contributing most of the interesting stuff at Planet
> > CCRMA to Extras).
> 
> I'm perfectly happy with you maintaining jack in extras. 

Good. If/when it makes it to Extras there's a lot of stuff waiting that
depends on it (for example Rosegarden, which was requested a couple of
days ago). 

BTW, good idea using /dev/shm, I have no idea why I didn't think of
that, it was a such a long time ago. Any objections from gurus out
there? I'll have to test it out for Planet CCRMA. 

> What sort of legal stuff do you have to go through?

Awh, just making sure I can sign all the legal papers........

> > Which brings me to a couple of comments. 
> > 
> > A proper usable release of Jack will need support at some level (kernel,
> > probably) for aquiring the proper privileges, ie: access to the
> > SCHED_FIFO scheduler and memory locking as a normal non-root user.
> > Without those two (specially the first) Jack is not really usable by
> > non-root users for its intended purpose. The current solution in the
> > Planet CCRMA kernels is to include the realtime lsm kernel module and
> > load it as part of the boot sequence. Regretfully the realtime lsm
> > kernel module cannot be built (last time I checked) as an external
> > module to the stock Fedora kernels as there is a kernel build option
> > that conflicts with it.
> 
> Well JACK is still usable even without privileges as an audio server. It
> probably dosen't gain anything over esd on its own, except that it lets
> you use some applications that require JACK. My plan with submitting it
> was to get JACK and some fun sound applications into FE now and sort out
> the kernel stuff once there was some momentum behind it. 

Sounds good to me. With the proviso that users should be warned, the
expectation of low latency performace is there otherwise, and users will
not get it unless they are willing to run everything as root (yuck!).

> I don't think
> the standard for FE kernel modules has been quite worked out yet (gdk?)
> so we might as well play with what we can.

Even if it had been worked out the lsm module cannot be built with the
existing Fedora kernel configuration, it needs:
  CONFIG_SECURITY_CAPABILITIES=m
instead of 
  CONFIG_SECURITY_CAPABILITIES=y
and both modules can't be stacked together (at least the last time I
tried it it was not working). 

> My package differs from the PlanetCCRMA one in that it doesn't care
> about preemption, realtime execution, or capabilities. 

Well, that is sort of independent of the package itself, I think. There
are no dependencies of any kind in both packages that presume access to
realtime stuff (with the exception of jackstart being suid root, only
needed for 2.4.x). You just can't run with "-R" as a non-root user
without the kernel support, but it will run. 

> So in some sense
> its merely a shadow of what JACK is "supposed" to be, but on the other
> hand it works out of the box without having to mess with the kernel, and
> without having to set LD_ASSUME_KERNEL.

[LD_ASSUME_KERNEL is not really necessary in the Fedora world, that was
a workaround for older versions of nptl (<= 0.60 if I remember
correctly) that had problems in spawning threads with the proper
inheritance of the scheduler class.]

But in essence what you say is true, either package, without the kernel
(or user level) support is not that usable, but _can_ be used. "jackd
-R" will not work, and users will definitely see lots of hiccups in
sound output, unless they are willing to work with quite long latencies
- something not really suitable for most of the applications that use
Jack. 

One question about the kernel support: would selinux be a potential
solution to the problem? Without messing with the kernel itself? Would
it be possible to use it (selinux) to grant access to SCHED_FIFO and
mlockall to selected users, groups of binaries??

-- Fernando