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/ -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
