Arch Linux

Could you please run the following and confirm whether or not you get the same errors (paste the output):

jackd -dalsa

Also let me know if you have lib32-jack2 installed. If you do, try one more thing, remove that and rerun the above command.

Here's the output:

jackd -dalsa
jackdmp 1.9.10
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2014 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
no message buffer overruns
JACK server starting in realtime mode with priority 10
self-connect-mode is "Don't restrict self connect requests"
audio_reservation_init
Acquire audio card Audio0
creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 2 periods for playback

Yes, I have lib32-jack2 installed on this system.
And here is the output with lib32-jack2 removed:

jackd -dalsa
jackdmp 1.9.10
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2014 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
no message buffer overruns
JACK server starting in realtime mode with priority 10
self-connect-mode is "Don't restrict self connect requests"
audio_reservation_init
Acquire audio card Audio0
creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 2 periods for playback

It looks like classic jackd is working fine. I want you to try the following:

A1. Keep jack2 installed instead of jack2-dbus
A2. Uninstall lib32-jack2, killall -9 jackd
A3. Run qjackctl (make sure to ENABLE DBUS mode)
A4. Start the server
A5. Get the output from Messages and paste here

---

B. Repeat A1-A5 except A2, i.e. reinstall lib32-jack2

---

C. Repeat A1-A5 with A2 intact (uninstall lib32-jack2), but change A1 now to install jack2-dbus.

---

D. Repeat C now with lib32-jack2 reinstalled.

I've recreated all the requested scenarios from the above,
and currently all seemed to be working (confused)

Here are the test results:

A1. Keep jack2 installed instead of jack2-dbus
A2. Uninstall lib32-jack2, killall -9 jackd
A3. Run qjackctl (make sure to ENABLE DBUS mode)
A4. Start the server
A5. Get the output from Messages and paste here


> pacman -Qs jack2
local/jack2 1.9.10-1
The next-generation JACK with SMP support


> cat var/log/qjackctl.log
http://pastebin.com/cwPWb1SJ

> ps awux | grep jack
USERNAME 14410 0.7 1.8 658964 150844 ? SLl 16:00 0:00 /usr/bin/qjackctl
USERNAME 14412 1.7 1.1 269664 92272 ? SLsl 16:00 0:01 /usr/bin/jackdbus auto


# RESULT: working


B. Repeat A1-A5 except A2, i.e. reinstall lib32-jack2


> pacman -Qs jack2
local/jack2 1.9.10-1
The next-generation JACK with SMP support
local/lib32-jack2 1.9.10-1
The next-generation JACK with SMP support (32 bit)


> cat var/log/qjackctl.log
http://pastebin.com/ZPhkHFtu

> ps awux | grep jack
USERNAME 14013 1.1 1.8 658964 150640 ? SLl 15:53 0:00 /usr/bin/qjackctl
USERNAME 14015 1.5 1.1 269664 92280 ? SLsl 15:53 0:00 /usr/bin/jackdbus auto


# RESULT: working


C. Repeat A1-A5 with A2 intact (uninstall lib32-jack2), but change A1 now to install jack2-dbus.


> pacman -Qs jack2
local/jack2-dbus 1.9.10-1
The next-generation JACK with SMP support (for D-BUS interaction only)


> cat var/log/qjackctl.log
http://pastebin.com/a8LtaBEC

> ps awux | grep jack
USERNAME 14909 1.6 1.1 333152 93064 ? SLsl 16:05 0:02 /usr/bin/jackdbus auto
USERNAME 14945 0.9 1.8 658964 151060 ? SLl 16:07 0:00 /usr/bin/qjackctl


# RESULT: working


D. Repeat C now with lib32-jack2 reinstalled.


> pacman -Qs jack2
local/jack2-dbus 1.9.10-1
The next-generation JACK with SMP support (for D-BUS interaction only)
local/lib32-jack2 1.9.10-1
The next-generation JACK with SMP support (32 bit)


> cat var/log/qjackctl.log
http://pastebin.com/88yXPsBW

> ps awux | grep jack
USERNAME 15367 1.1 1.8 658964 151348 ? SLl 16:11 0:00 /usr/bin/qjackctl
USERNAME 15369 1.4 1.1 269664 92208 ? SLsl 16:11 0:00 /usr/bin/jackdbus auto


# RESULT: working

I've reviewed recent system updates (since the incident),
but nothing seems related to audio system.
I regret I forgot to get the hash of the lib (jack_alsa.so),
I can compare if it changed since started troubleshooting.

But now it seems to be working on that system (really hate when
that happens - starts working, not knowing why it stopped and
why started again).


Anyway, thanks a lot for the support. Appreciated

Sure, thanks for testing. This was most likely a corner case of a running program looking somewhere it shouldn't have (where the symbol does not exist), though I only say this with hindsight. Otherwise, we do have proof that this should not have occurred:

$ scanelf -l -s _ZN4Jack10JackDriver15SaveConnectionsEi | grep _ZN4Jack10JackDriver15SaveConnectionsEi
ET_DYN _ZN4Jack10JackDriver15SaveConnectionsEi /usr/lib/libjackserver.so.0.1.0
ET_DYN _ZN4Jack10JackDriver15SaveConnectionsEi /usr/lib/libjackserver.so.0.1.0

I am unable to explain this without having it being reproducible. Might this have been solved with a new instance of jack(dbus) or ldconfig? Perhaps. I will close this if you confirm again that everything's working as expected.

One scenario that comes to mind, though, is having a jackdbus instance running, updating, and trying to start jack again (via dbus). You can uninstall the update, reinstall the old packages, run ldconfig, start jack, update, and see if you can reproduce it that way.

Note: Sorry, I should've told you to pastebin instead. I've gone ahead and edited your comment to include pastebin links replacing the long pastes.

You were right on with the last scenario:

"One scenario that comes to mind, though, is having a jackdbus instance running, updating, and trying to start jack again (via dbus). You can uninstall the update, reinstall the old packages, run ldconfig, start jack, update, and see if you can reproduce it that way."

> pacman -Qs jack2
local/jack2-dbus 1.9.9.5-4
The next-generation JACK with SMP support (for D-BUS interaction only)
local/lib32-jack2 1.9.10-1
The next-generation JACK with SMP support (32 bit)

> sudo pacman -S jack2-dbus

> pacman -Qs jack2
local/jack2-dbus 1.9.10-1
The next-generation JACK with SMP support (for D-BUS interaction only)
local/lib32-jack2 1.9.10-1
The next-generation JACK with SMP support (32 bit)

# stop and start via qjackctl

> cat var/log/qjackctl.log
Thu Aug 28 19:09:17 2014: Released audio card Audio0
19:09:19.231 D-BUS: JACK server could not be started. Sorry
Thu Aug 28 19:09:19 2014: Starting jack server...
Thu Aug 28 19:09:19 2014: JACK server starting in realtime mode with priority 80
Thu Aug 28 19:09:19 2014: ERROR: Can't load "/usr/lib/jack/jack_alsa.so": /usr/lib/jack/jack_alsa.so: undefined symbol: _ZN4Jack10JackDriver15SaveConnectionsEi
Thu Aug 28 19:09:19 2014: ERROR: Cannot initialize driver
Thu Aug 28 19:09:19 2014: ERROR: JackServer::Open failed with -1
Thu Aug 28 19:09:19 2014: ERROR: Failed to open server
19:09:21.254 Could not connect to JACK server as client. - Overall operation failed. - Unable to connect to server. Please check the messages window for more info.
Thu Aug 28 19:09:21 2014: Saving settings to "/home/USERNAME/.config/jack/conf.xml" ...

Sorry I've wasted your time, and thanks again for the support.

P.S. I'll follow the pastebin policy from now on.

P.P.S. I confirm everything is working as expected

OK, so I've successfully reproduced this and it looks like it's partly an upstream issue (provided the runtime behaviour can be changed). The problem only exists with jackdbus, which is started by a control application such as qjackctl.

When you use the control application to start and stop the jack server, regardless of whether you quit the app, jackdbus is not terminated. This is the background dbus communication service, so it must always run. However, it also loads and has the server library in memory.

When you then change your installation of jack(dbus), and compiled objects are different, the background service tries to communicate with the server in order to start it but fails when there is a symbol lookup error (the library in memory is stale).

I'm not sure whether this has always been the case, but the interim solution to this is to kill jackdbus before starting the server, after an upgrade. I'm just surprised nobody experienced this so far (if it has indeed been the behaviour all along).

Anyway, glad it's not a show-stopper. Closing.