[PlanetCCRMA] the jack permissions conundrum

[Fernando Lopez-Lezcano]

On Sun, 2010-05-30 at 15:33 -0700, Niels Mayer wrote:
> > 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. 

A logout/login cycle is (should be) enough. I think the lookup is done
at authentication time. 

> 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

To be expected, when you run out of disk space in "/" (or /home, for
that matter), many things stop working :-) I have at times spent some
time puzzled as to why something stopped working till I realized the
disk was full. 

That reports points to a bug in jack_1_ 0.116.x. 

This is what happens under the same conditions in jack2:

----
$ jackd -R -d alsa -d hw:0
jackwrapper: pacmd suspend 1
jackdmp 1.9.5
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2009 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
no message buffer overruns
no message buffer overruns
JACK server starting in realtime mode with priority 60
Cannot lock down memory area (Cannot allocate memory)
jackwrapper: pacmd suspend 0
----

So it exits properly and prints some error message (not too specific,
but it does not crash)...

-- Fernando