Re: fw: jackd/ audio apps mini policy
Zenaan Harkness <zen@iptaustralia.net> writes:
> > 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
Some people have reported good results running jackd without realtime
privileges using larger buffers (hence larger latencies). For me,
running Debian without SMP, this does not work well at all. The
largest buffer my soundcard supports is 2048 frames, and I still get
frequent overruns whenever the X server is active.
Someone told me that Debian runs the X server with nice -10 (or
something). This might explain why non-realtime audio works OK for
others but not for me. It also seems to work better for people using
SMP machines, perhaps for the same reason.If I could find where this happens I would experiment
with turning it off.
> 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:
- capabilities enabled
> - 686 processor optimized, MMX, SSE, etc ??
> - follow existing kernel-image-... package naming conventions (roughly)
> - lowlatency
> - preempt
> - ALSA (no OSS, ie remove legacy ??)
> > 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 ?
> 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...
This could be done. Jackstart tries to be very careful to ensure that
it only starts the *real* jackd, checking ownership, permissions and
md5 checksum. That could be generalized, I suppose, along the lines
of /etc/sudoers.
If only the required realtime capabilities could do without
CAP_SYS_RESOURCE, I would advocate opening them up to any process in
group `audio'. The advantage of this is that if all audio
applications automatically got realtime privileges, there would be no
need to delegate CAP_SETPCAP, which is the danger the kernel gurus
fear, AFAICT. There would be no need for a special starter program,
one could just do...
# chgrp audio foo
# chmod g+s foo
I'm not sure what the problem is with CAP_SYS_RESOURCE. Both Nando
and I tried to run jackstart and jackd without it. Neither of us
could get it to work that way. It fails on the call to mlockall().
Looking at the kernel sources, it only checks `capable(CAP_IPC_LOCK)'
explicitly. I suppose there must be some hidden resource allocation
going on somewhere else that requires this. Maybe this is just a bug
in the kernel and someone could fix it.
--
Jack O'Quin
Austin, Texas
Reply to: