[PlanetCCRMA] the jack permissions conundrum

[Niels Mayer]

> If you suspect a problem with the rt priorities, again, it is rather
> easy to _check_ if that is the case. Change /etc/security/limits.conf so
> that either the limits that the Planet CCRMA jack puts there are
> commented out or lower. Logout, login again and try again.

I thought you needed to reboot to have /etc/security/limits.conf
changes take effect. Which is part of the reason I have not debugged
all the different variants of this, and my preference is to not debug
any of it :-) However, when your computer locks up, you start taking
note of things... of at least trying to change the behavior that
causes massive disruption and time wastage.

The latest thing I've learn't not to do (much like removing spoon from
coffee to prevent eye from being poked out :-) ):  setting either of
these switches to "on" on my ICE1724 (Dynex dx-sc51):
Simple mixer control 'Multi Track Rate Locking',0
Simple mixer control 'Multi Track Rate Reset',0
And rebooting, then trying to use qjackctl. (After turning the
switches off in alsamixer, and rebooting again, everything works
fine).

The nature of the lockup is that it happens out of qjackctl, but can
be stopped by either killing jackd, or qjackctl (and then separately
killing hung jackd). It is an X-server lockup, or directly locks up
USB bus s.t. keyboard input is never processed (including Ctl-Alt-Del,
Ctl-Alt-Bksp, Alt-F1-8, etc). If qjackctl is displaying to a remote
machine -- then the remote machine's X server will be locked up until
qjackctl or jackd are killed.

The only thing you can do is go to a host with a different X server
(that isn't locked up), and kill the offending processes via SSH.

This is probably a different issue entirely than your current concern
w/ packaging jack2. I have not tried turning off rt prio and seeing if
I can reproduce the lockup.... so I have no idea if it is a priority
lockup. What I do know is that I never see lockups like that normally.

...........

Also, the following bug is a good example of how potentially
conflicting Shared-memory settings between Jack and Pulseaudio could
result in pulseaudio-related Jackd issues:
https://bugs.launchpad.net/ubuntu/+source/jack-audio-connection-kit/+bug/491329

-- Niels
http://nielsmayer.com