[Slackbuilds-users] realtime capabilities for jack and its apps

[B Watson]

On 8/21/11, David Woodfall <dave at dawoodfall.net> wrote:

> It was mentioned to me and the other guys working on the Studioware
> project to do this and I will be adding it to our jack and
> jack-audio-connection-kit slackbuilds soon, with an appropriate test
> for -x /sbin/setcap etc. but only for those applications. I don't
> really see the point of adding it to other audio apps if when jack is
> installed setcaps is run. It may be that qjackctrl needs realtime too
> but I haven't had time to test this yet.

qjackctl does need it... but so does ardour (and rosegarden, and ecasound,
and jack-rack, and rakarrack, and anything else that does audio capture
and/or can apply LADSPA or LV2 effects during playback, in realtime),
and anything that's a synthesizer or sampler (like hydrogen, bristol,
fluidsynth/qsynth, aeolus, zynaddsubfx, linuxsampler, etc). Even stuff
like lingot (guitar tuner) and japa (oscilloscope/meter) benefit from it.

Ardour will actually pop up dialog boxes at startup warning you if it
can't set realtime priority and/or lock enough memory... and the Ardour
web site has directions (for PAM systems only) on how to set it up. So
I'm not the only one who thinks it's necessary...

Pretty much anything that lists libjack.so in its ldd output will need
it, in my experience. Eh, so I wrote a script to look for just that
(attached), and set the caps on everything in /usr/bin that has it. But
doing it in the package system seems like a cleaner approach.

If you're running on a really high-end system (4+ cores, 1GHz+
frontside bus, really nice M-Audio pro audio interface), you might not
have any x-runs no matter what you do... but we can't all afford that,
and I promise, the realtime cap bits make a big difference trying to use
jack & its apps on an older or budget machine. And also on some of those
really high-end machines, depending on what hardware's in 'em. If you're
recording yourself playing guitar, singing, whatever... you can't afford
to have *any* x-runs during recording, if you want professional results.

BTW, I am one of the other guys working on the studioware project :)
(though I haven't been all that active lately)

> I can see making jackd audio group only would be a safer option, but
> aren't most users in the audio group anyway?

The audio-group-only idea might be nice, but maybe not essential. Binaries
with extra capabilities aren't as dangerous as setuid root binaries,
but they maybe should still be handled with care.

> I'll watch this thread with interest anyway.

Yeah. I'm hoping to hear from other people (so far it's mostly been
me ranting & raving, it'd be much better to have lots of opinions &
a discussion).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fixrtcaps.gz
Type: application/x-gzip
Size: 595 bytes
Desc: not available
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20110821/cd3a3881/attachment.bin>