[PlanetCCRMA] Re: Running JACK as non-root user

Artem Baguinski artm@v2.nl
Thu Dec 2 01:41:01 2004


Kevin Ernste <kevinernste@gmail.com> writes:

>> 23:00:29.563 Statistics reset.
>> 23:00:29.570 JACK is starting...
>> 23:00:29.571 /usr/bin/jackd -v -R -dalsa -dhw:0 -r48000 -p64 -n2
>
> I hope it's this easy, but are you using "jackstart" with qjackctl
> (look in "Setup...-->Server Path" in qjackclt)?  I think this is
> needed instead of "jackd" for the privelages you want.
>
> http://ccrma.stanford.edu/planetccrma/man/man1/jackstart.1.html

Just recently I read a thread on jack mailing list where they say that
jackstart is 2.4 kernel specific, although should work (simply passing
control to jackd) with 2.6 kernel. But that means jackd should work. 

Nevertheless if I try to use jackd I get the same result as
Jean-Baptiste (can't lock down memory for jack).

And BTW from JACK FAQ:

   There is an allcaps=1 option, which duplicates the effect of
   running Linux 2.4 with the capabilities patch. To use that you must
   compile JACK with --enable-capabilites as you would for the 2.4
   kernel. You will need this if you prefer to run jackstart -R rather
   than jackd -R. If you only use Linux 2.6, you need not bother with
   it.

Aha! that explain everything, no?

But I read further:

    Currently (as of 2.6.7) JACK has a serious problem creating
    SCHED_FIFO threads for real-time processing. It is unclear whether
    this is a bug in JACK, in the new Native PThreads Library (NPTL),
    or in the 2.6 kernel. At the moment no one has a solution, but
    there is a workaround: define LD_ASSUME_KERNEL=2.4.19 in the
    environment of the jackd process and of every JACK client.

I don't have this variable set and I have no idea if JACK has these
"serious problem". But I do experience some funny behaviour that I'm
trying to explore further before reporting. I just don't know if it
has anything to do with SCHED_FIFO threads.

NB: they did say FAQ was abit out of date on jack mailing list. namely
latest jackstart should work no matter what.

> And since you're asking for techniques to make it work, I like to
> create a group "audio" and then add myself and or other users to that
> group (say it ends up being group 501).  Then when you load realcap do
> it with:
>
> /sbin/modprobe allcaps=1 gid=501

you meant:

/sbin/modprobe realcap allcaps=1 gid=501

right? 

> You can even just edit the init script that Fernando mentions to make
> this load this way at boot.
>
> http://ccrma.stanford.edu/planetccrma/root/etc/rc.d/init.d/realcap
>
> The spot where it says:
>
> REALCAP_OPTS="allcaps=1"
>
> Change to:
>
> REALCAP_OPTS="allcaps=1 gid=501"
>
> Kevin