[PD] a/d/a and jackd alsa low-latency problems

[FrankBarknecht]

Hallo,

(I cc the list again, as it might help others later as well)

thewade hat gesagt: // thewade wrote:
> On Tue, 19 Oct 2004, Frank Barknecht wrote:
> > The clean way is, not to run jackd nor Pd as root, but give both
> > higher priorities. For Pd this unfortunatly means \"chmod +s
> > /usr/bin/pd\" which is still more secure than running as root, and
> > jackd can be started as normal user through \"jackstart\" if you have a
> > capabilities-patched 2.4 or 2.6 kernel, or as user, if you use the
> > realtime-lsm module.
> 
> This describes one of the holes in understanding for me, as a result of
> self-teaching linux. The +s is setuid bit, right? How does this increase
> priority? I thought nice controlled priority...
> Ive tried jackd -R ... as myself and it cannot initiate a thread, so I
> proabably do not have capabilities, right? Even if I am running
> 2.6.9-rc3-mm3-VP-T3?

Nice also controls priority, but 

a) you cannot raise priority unless you are root, and 

b) there are different kinds of priorities. 

"Capabilities" is the word to remember in this context.  To get a) out
of the way, you can run applications as root, which will give a
software all capabilities. Including the capability to crash your
machine, to  delete your harddisk or to send banking and mail ebay
passwords of all users on your system to a hacker site. 

Many people try not to risk something like this. It's also not
necessary to risk it, because getting at ebay passwords will not give
you lower latency. To get lower latency, Pd or Jack only need to get
"a little bit of root". They need to lock memory in RAM, so no random
harddisk access by swapping will happen during low latency operations.
And they need to get a higher priority when it comes to being served
by the kernel prior to other processes. This is called SCHED_FIFO.

M_LOCK and SCHED_FIFO are not normally changeable by software running
as a non-root user. By doing a "chmod +s /usr/bin/pd" (or on Debian:
"dpkg-statoverride --add root root 4755 /usr/bin/pd"), Pd gets "setuid
root", which means, it will run with all priviledges root has.
Including that ebay thing. 

But I'm personally convinced, that Miller is not interested in your
ebay passwords. That's why Pd drops all root priviledges immediatly,
after it has scheduled itself SCHED_FIFO and locked all memory.

You can check this yourself: do the chmod. Find some file, that is not
available to you normally, only to root. /etc/passwd or /etc/shadow
are good candidates. Then create a simple patch and try to 
[read /etc/shadow cr( -> [textfile]. Although Pd is setuid root, it
will not be able to read the file: 

error: /etc/shadow: can't open
error: /etc/shadow: read failed

Because after doing the M_LOCK and the SCHED_FIFO, Pd actually becomes
*your* program again.

However: For various technical reasons this does not work with jackd.
If you setuid root jackd, you're effectivly shutting out all non-root
access to the jack-server. 

For Jack, there are two alternative routes: One is using jackstart and
the so called "Capabilities patch". The other involves the
realtime-lsm module for kernel 2.6.x.

The C. patch is described in detail on the jackit.sf.net page: You
need to edit one kernel header, then recompile and use jackstart to
start jackd. jackstart needs to be setuid root, jackd must not be
setuid root. A/DeMuDi or Planet CCRMA with kernel 2.4.X do it this
way.

The realtime-lsm module OTOH allows you to define a user or a group of
users (often the group called "audio"), that can access the M_LOCK and
SCHED_FIFO capabilities without being root. In that case, at least
jackd doesn't have to be setuid root, I don't know if this works with
Pd as well without pd being setuid too, but I think, it will. (I still
run a C. patched kernel.)

> > Whooho, 64 already is *very* small. I never heard of anybody run
> > jack with 32.  That\'s almost hard-realtime!
>
> Perhaps the smallest buffersize I can get with my Hammerfall
> Multiface is 64. When I run jackd -v Im only using one quarter of my
> available time though...

It's not clear to me, what "time" are you talking about here?  CPU
time has nothing (or not much) to do with low latency. Pd's lowest
latency is always a lot bigger than Jack's anyway, because Pd is using
an auxiliary buffer. Latency is the maximum time needed to *react* to
something. It's not a measure of system load or so.

A period of 64 with "-n 2" will give you a latency at CD quality of
2*64/44100 = 3 msecs. That's very low latency. With 32 it will become
1.5 msecs and with 8 it will be a latency of 0.3 msecs.

I'm normally very happy with 128 or 256 on my laptop, which at 48kHz
will be a latency of 10 msec, but that's a stable latency.

Ciao
-- 
 Frank Barknecht                               _ ______footils.org__