Re: fw: jackd/ audio apps mini policy
On 4 Nov 2003, Jack O'Quin wrote:
> 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.
My experience in general is that it doesn't work that good ...
Seems to depend largely on type of soundcard too.
>
> 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.
Its in /etc/X11/Xwrapper.config
Seems that it is changeable with debconf
-- snip ---
### BEGIN DEBCONF SECTION
# Do not edit within this region if you want your changes to be preserved by
# debconf. Instead, make changes after the "### END DEBCONF SECTION" line.
allowed_users=console
nice_value=-10
### END DEBCONF SECTION
-- snip ---
>
> > 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
>
Zenaan:
> > - 686 processor optimized, MMX, SSE, etc ??
> > - follow existing kernel-image-... package naming conventions (roughly)
> > - lowlatency
> > - preempt
> > - ALSA (no OSS, ie remove legacy ??)
This is probably not a good idea (remove the legacy mode).
Also it might not harm to leave the OSS modules in the kernel.
ALSA is a separate package in 2.4, so we have to build our own
alsa modules anyway.
> > > 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.
Thats interesting, I am just guessing here, but probably the mlockall
needs the whole program loaded into RAM, and this process needs
CAP_SYS_RESOURCE ... ? (This is a really wild guess, to tell the truth
I don't have any idea).
Guenter
Reply to: