19 Nov
2015
19 Nov
'15
3:37 a.m.
Can anyone provide some insight into the following JACK error?
Cannot open lsp client
jack_client_open() failed, status = 0x21
Background: SuperCollider has an extension class, SCJConnection[1], that uses jack_lsp to
query a running jack server for ports, properties and connections. This has never failed
for me. In fact, at 8 AM today, it was fine. Then I needed to step away, so I closed audio
apps, stopped the Jack server (using qjackctl) and suspended my Ubuntu session. A bit
later, I resumed the session, restarted the Jack server, launched SC, and it spit out
"Cannot open lsp client" for the same action that had worked perfectly two hours
before.
Quitting and restarting the Jack server did not resolve the problem.
Rebooting the computer resolved the problem.
If it's impossible to determine the cause at this point, that's fine -- I've
seen stranger things from computers. But it's troubling that something that has worked
literally thousands of times would suddenly, today, fail for no apparent reason. So
I'm hoping maybe somebody might have a guess what would cause lsp to break (and I can
keep that in mind if it happens again).
hjh
[1]
https://github.com/supercollider-quarks/LinuxExternal/blob/master/JACK/SCJC…
19 Nov
19 Nov
10:19 a.m.
On 11/18/2015 04:37 PM, James Harkins wrote:
Can anyone provide some insight into the following
JACK error?
Cannot open lsp client jack_client_open() failed, status = 0x21
Background: SuperCollider has an extension class, SCJConnection[1],
that uses jack_lsp to query a running jack server for ports,
properties and connections. This has never failed for me. In fact, at
8 AM today, it was fine. Then I needed to step away, so I closed
audio apps, stopped the Jack server (using qjackctl) and suspended my
Ubuntu session. A bit later, I resumed the session, restarted the
Jack server, launched SC, and it spit out "Cannot open lsp client"
for the same action that had worked perfectly two hours before.
Quitting and restarting the Jack server did not resolve the problem.
Rebooting the computer resolved the problem.
If it's impossible to determine the cause at this point, that's fine
-- I've seen stranger things from computers. But it's troubling that
something that has worked literally thousands of times would
suddenly, today, fail for no apparent reason. So I'm hoping maybe
somebody might have a guess what would cause lsp to break (and I can
keep that in mind if it happens again).
hjh
[1]
https://github.com/supercollider-quarks/LinuxExternal/blob/master/JACK/SCJC…
My general experience has been that very little audio hardware handles
suspension. My USB soundcard, for example, does not. But you said lsp
was working before you suspended, so I have no idea beyond Ubuntu
sneaking in an update????
--
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
20 Nov
20 Nov
3:18 a.m.
Thanks, David, for the reply.
My normal practice for suspending the session is to stop the Jack server first. I've
also configured PulseAudio *not* to start itself, so at the time I suspend the session,
there is no process actively using the audio hardware. After resuming the session,
that's when I restart the Jack server and this fires up the ALSA driver.
Weird.
hjh
10:34 a.m.
On 11/19/2015 04:17 PM, James Harkins wrote:
Thanks, David, for the reply.
My normal practice for suspending the session is to stop the Jack server
first. I've also configured PulseAudio *not* to start itself, so at the
time I suspend the session, there is no process actively using the audio
hardware. After resuming the session, that's when I restart the Jack
server and this fires up the ALSA driver.
Hmm, I thought ALSA drivers loaded during boot, not when JACKD tries to
start? I only use JACK when I'm making music - but can still play audio
from programs that don't use JACK, without starting JACK. (I have no
trace of PulseAudio on my system).
Don't know for certain about audio hardware, but was quite familiar with
network hardware (usually wireless) for which system drivers set the
device state at load and/or when a connection was established. When the
system was suspended, everything went to sleep/hibernated/whatever -
except the hardware.
The state of the hardware could change when the system was suspended.
(Or in the case of network hardware, the state of the network would
change.) In fact, if it was "hibernate to disk, then shut off",
guaranteed the state of the hardware changed. When a system comes up
from a cold state like that and loads a hibernation image, does the
hibernated system reload any required firmware, for instance?
When the system resumed from suspension, the drivers just assumed that
"their" device was in the same state as before ... leading to failure.
That was a good while ago, don't know if it's still an issue. Just an idea.
Weird.
hjh
Yah.
--
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
3325
days inactive
3326
days old
linux-audio-user@lists.linuxaudio.org
3 comments
2 participants
participants (2)
-
david -
James Harkins