Re: fw: jackd/ audio apps mini policy
On Tue, 2003-11-04 at 20:08, guenter geiger wrote:
> Hi, thanks for your explanations,
Courtesy the old(er) hats on debian-mentors. I essentially just collated
the responses to my questions. You're welcome.
> The way I see it the only solution to have realtime functionality
> with JACK is to build a capability and lowlatency patched kernel and set
> jackstart suid root via the debconf system.
That certainly seems to be the consensus and it sounds right to me.
> Setting jackd root does not work, because in that state JACK does not
> accept clients started from users.
:)
Yes, I have discovered this - had me scratching my head for quite some
time initially.
> Anyhow, as JACK is not of too much use without the lowlatency patched
> kernel, this is the only option we currently have.
... for "professional audio". Agreed. And then jackd is still runnable
by anyone as per standard expectations of debian policy.
jackstart = bonus
> I don't know what is involved in uploading kernel images to debian,
> we would have to check that. I am going to try to figure that out,
> if we can agree on this policy.
I think we've just about hashed all possibilities for the policy.
For kernel, either debian-devel, or herbert@d.o (the current debian
kernel-image-... etc, maintainer - he's very cluey). From the bits I've
read so far on d-devel, it seems that all that is required is creation
of a package and probably an ITP for the custom kernel. That will
naturally invite discussion on d-devel, which would be good.
I think a multi-media specific kernel will be generally appreciated.
Also, the steps involved in creating it would be good do list here
somewhere, so that those with lower- or higher-spec hardware can
customize it.
debian-multimedia custom kernel desired features:
- 686 processor optimized, MMX, SSE, etc ??
- follow existing kernel-image-... package naming conventions (roughly)
- lowlatency
- preempt
- ALSA (no OSS, ie remove legacy ??)
- full kernel package set, a la herbert's existing package conventions
(eg. kernel-source-2.X.YY, kernel-headers-2.X.YY, etc)
- do we build on top of herbert's existing kernels (with his selected
patches - my recommendation) or roll our own from vanilla sources? I
tend to think that there must be a certain amount of work going into
establishing what are "good" default options (there are 100s and 100s of
these) that work well for most people, as well as little stability
patches, etc, etc, that it would be good to build on, rather than
rediscovering these ourselves...
- also, the standard packages have everything modularised - eg. NICs,
video drivers, pcmcia, etc, etc - again, it is presumably a big win to
build on top of this.
Perhaps (a la gentoo), our -multimedia kernel package is in fact just a
script that takes the existing kernel, adds in the kernel-patch-2.X...
patch packages we need, optionally downloads and installs additional
patches we recommend, and even auto-detects (and confirms) CPU type to
get maximally optimal kernel for each user. This is my top preferred
route - running status (ie verbose make-kpkg output) to keep user happy
that something is happening while it all happens (after pre-config).
By building on existing programs, ie. make-kpkg (from kernel-package
package) it should be "relatively" straightforward for someone with
enough know-how and time...
> Of course the JACK package should then at least recommend the
> multimedia kernel.
Good.
> For audio apps I think it should be the decision of the application
> packagers.
To what - recommend multimedia-kernel? - I'd agree.
> All this will introduce security risks, maybe there is a
> way to write a general audio apps starter that gives the required
> capabilities (RT sched and memlocking) to the soundapps ?
Yes, this would be ideal. jackstart is apparently already that -
as per earlier d-mm email:
On Sun, 2003-11-02 at 05:40, Jack O'Quin wrote:
> Zenaan Harkness <zen@iptaustralia.net> writes:
> > I thought jackstart was essentially equivalent to a generic wrapper
> > - both require RTcap-patched kernel. Which would mean the only
> > difference between 2 and 3 here is the use of jackstart vs. generic
> > wrapper, where jackstart is more intelligent about jack command
> > line args. ??
>
> Actually, jackstart knows nothing about jackd command args. It is a
> minimal trusted program written by Fernando Lopez-Lezcano (of Planet
> CCRMA fame) for invoking jackd with realtime capabilities as carefully
> as possible. From the comments...
>
> Jackstart is based on code and concepts found in sucap.c, written by
> Finn Arne Gangstad <finnag@guardian.no> and givertcap.c, written by
> Tommi Ilmonen, Tommi.Ilmonen@hut.fi
(see email archives for more)
jackstart might not need much changes, except perhaps a more
generic name and some other names (via symlinks or whatever
config) to run appropriate prog...
regards
zenaan
Reply to: