Creating a jackuser group

[Florin Andrei]

Dan Williams wrote:
> 
> Hmm; I wonder if there are better ways to do this.  Debian/Ubuntu use
> groups for networking stuff, and, for example, you can't talk to
> NetworkManager unless you're in the 'netdev' group.  Which is odd.

We also have to take into consideration what the upstream recommends.

http://jackit.sourceforge.net/docs/faq.php#a52

Realtime groups seems to be the recommendation from upstream.

> So lets think about the user experience here.  If somebody installs an
> app that uses Jack or requires realtime audio capabilities, what's the
> failure mode if they're not in the 'rtaudio' group?  How would they know
> what to do to be able to do realtime audio?  How do they get told that
> they need to got to system-config-users, enter the root password, and
> add themselves?

Best-case scenario, the apps will silently drop RT capabilities. 
Everything will just work fine, except when there's a CPU load spike, 
when jackd may or may not drop a few chunks of audio stream. That may 
get noticed by the user as clicks and pops, or not, depending on many 
factors. Most of the time on an otherwise idle system, there will be no 
difference.

Worst-case scenario... I guess someone with more experience should chime 
in here. I don't think there's any difference from the best-case I just 
described. At least, I can't remember any situation when anything 
happened that was worse than the best-case described above (silent 
dropping of RT capabilities).
If I'm not mistaken, it's just jackd that actually has to acquire RT. 
The other JACK-enabled apps just hook up into that. But feel free to 
correct me if I'm wrong.


Finally, please keep in mind that RT capabilities are more of an 
advanced user thing. Well, that's debatable, of course, but people who 
absolutely need RT and cannot live without it are probably those who 
load up a bunch of synths on a laptop, hook up a MIDI keyboard and 
perform on stage.
Also, enthusiasts like me will arguably need RT as a basic requirement 
that cannot be replaced by something else.

All these people will be glad to click on a pop-up, enter a root 
password and do such things to enable RT. This will be perceived as an 
improvement over the current situation, which requires reading docs, 
making manual changes to obscure system files (with the potential to 
break the whole system) and stuff like that.

The most casual users (those who may test ZynAddSubFX a couple times 
then forget it) do not need RT, and can simply dismiss a pop-up with few 
ill effects (the performance will remain at the default non-RT level). 
But if the user interaction is simple enough ("enter root password to 
enable RT for best audio performance") then why not give them that 
capability?

-- 
Florin Andrei

http://florin.myip.org/