17 Oct
2015
17 Oct
'15
5:58 p.m.
Hi all,
This is a long-standing problem. While it is not intentional, sometimes
newcomers to jack on Linux tend to pull out the soundcard (USB) before
shutting down jack. This results in jack permanently hanging to the
point where one has to force-shutdown the machine. That is at least the
case on Ubuntu 14.04 (and was on 12.04) with lowlatency kernel. Trying
to do sudo killall -9 jackd makes no difference. Essentially, it is
impossible to destroy the process and reboot hangs because of it.
Any idea what can be done to minimize this problem or alleviate it
altogether?
Best,
Ico
--
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
ico(a)vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
17 Oct
17 Oct
6:24 p.m.
On Sat, 17 Oct 2015 13:58:37 -0400
Ivica Ico Bukvic <ico(a)vt.edu> wrote:
Hi all,
This is a long-standing problem. While it is not intentional, sometimes
newcomers to jack on Linux tend to pull out the soundcard (USB) before
shutting down jack. This results in jack permanently hanging to the
point where one has to force-shutdown the machine. That is at least the
case on Ubuntu 14.04 (and was on 12.04) with lowlatency kernel. Trying
to do sudo killall -9 jackd makes no difference. Essentially, it is
impossible to destroy the process and reboot hangs because of it.
Any idea what can be done to minimize this problem or alleviate it
altogether?
Best,
Ico
a workaround is from a terminal type:
pidof jackd
you'll get a number such as 3772
then type
kill -9 3772
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
6:31 p.m.
On Sat, 17 Oct 2015 19:24:02 +0100
Will Godfrey <willgodfrey(a)musically.me.uk> wrote:
On Sat, 17 Oct 2015 13:58:37 -0400
Ivica Ico Bukvic <ico(a)vt.edu> wrote:
Hmm, just reread. All I can say is it works for me and with just kill and no
sudo :o
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Hi all,
This is a long-standing problem. While it is not intentional, sometimes
newcomers to jack on Linux tend to pull out the soundcard (USB) before
shutting down jack. This results in jack permanently hanging to the
point where one has to force-shutdown the machine. That is at least the
case on Ubuntu 14.04 (and was on 12.04) with lowlatency kernel. Trying
to do sudo killall -9 jackd makes no difference. Essentially, it is
impossible to destroy the process and reboot hangs because of it.
Any idea what can be done to minimize this problem or alleviate it
altogether?
Best,
Ico
a workaround is from a terminal type:
pidof jackd
you'll get a number such as 3772
then type
kill -9 3772
6:43 p.m.
On Sat, 17 Oct 2015, Will Godfrey wrote:
On Sat, 17 Oct 2015 19:24:02 +0100
Will Godfrey <willgodfrey(a)musically.me.uk> wrote:
> On Sat, 17 Oct 2015 13:58:37 -0400
> Ivica Ico Bukvic <ico(a)vt.edu> wrote:
>>
>> This is a long-standing problem. While it is not intentional, sometimes
>> newcomers to jack on Linux tend to pull out the soundcard (USB) before
>> shutting down jack. This results in jack permanently hanging to the
>> point where one has to force-shutdown the machine. That is at least the
>> case on Ubuntu 14.04 (and was on 12.04) with lowlatency kernel. Trying
>> to do sudo killall -9 jackd makes no difference. Essentially, it is
>> impossible to destroy the process and reboot hangs because of it.
>>
>> Any idea what can be done to minimize this problem or alleviate it
>> altogether?
>
> a workaround is from a terminal type:
>
> pidof jackd
>
> you'll get a number such as 3772
>
> then type
>
> kill -9 3772
>
May need to be:
killall -9 jackdbus
Generally, when someone asks they get told:
killall -9 jackd jackdbus
:)
But by default Qjackctl as it comes from ubuntu repos starts jackdbus, not
jackd.
--
Len Ovens
www.ovenwerks.net
6:44 p.m.
On Sat, Oct 17, 2015 at 07:24:02PM +0100, Will Godfrey wrote:
On Sat, 17 Oct 2015 13:58:37 -0400
Ivica Ico Bukvic <ico(a)vt.edu> wrote:
That's what killall or pkill will do anyway, so
I don't think this is a solution.
I also don't think that Jack is involved. You'd
probably get the same effect when unplugging the
USB device while some ALSA app is using it.
There is a similar problem with the hdsp-madi module,
and it has hit me a number of times when installing
the card in a new system. Apparently the default
configuration expects an external clock, and when
that isn't connected any process that uses the device
hangs and can't be killed. The first process to do so
will be alsactl, called as part of the boot sequence.
And since that will be called again as part of reboot
or poweroff, those will hang as well. The only thing
you can do to pull the power plug, remove the card,
boot, edit the file used by alsactl, switch off, put
the card back and boot.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
Hi all,
This is a long-standing problem. While it is not intentional, sometimes
newcomers to jack on Linux tend to pull out the soundcard (USB) before
shutting down jack. This results in jack permanently hanging to the
point where one has to force-shutdown the machine. That is at least the
case on Ubuntu 14.04 (and was on 12.04) with lowlatency kernel. Trying
to do sudo killall -9 jackd makes no difference. Essentially, it is
impossible to destroy the process and reboot hangs because of it.
Any idea what can be done to minimize this problem or alleviate it
altogether?
Best,
Ico
a workaround is from a terminal type:
pidof jackd
you'll get a number such as 3772
then type
kill -9 3772
7:19 p.m.
On Sat, 17 Oct 2015 18:44:40 +0000
Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Sat, Oct 17, 2015 at 07:24:02PM +0100, Will Godfrey
wrote:
Interesting. I just tried this on my 'office' machine with a KA6 and it worked,
albeit the response was like treacle! I wonder if the fact that the default
motherboard sound was *not* disabled might have had some bearing on it.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
On Sat, 17 Oct 2015 13:58:37 -0400
Ivica Ico Bukvic <ico(a)vt.edu> wrote:
That's what killall or pkill will do anyway, so
I don't think this is a solution.
I also don't think that Jack is involved. You'd
probably get the same effect when unplugging the
USB device while some ALSA app is using it.
There is a similar problem with the hdsp-madi module,
and it has hit me a number of times when installing
the card in a new system. Apparently the default
configuration expects an external clock, and when
that isn't connected any process that uses the device
hangs and can't be killed. The first process to do so
will be alsactl, called as part of the boot sequence.
And since that will be called again as part of reboot
or poweroff, those will hang as well. The only thing
you can do to pull the power plug, remove the card,
boot, edit the file used by alsactl, switch off, put
the card back and boot.
Ciao,
Hi all,
This is a long-standing problem. While it is not intentional, sometimes
newcomers to jack on Linux tend to pull out the soundcard (USB) before
shutting down jack. This results in jack permanently hanging to the
point where one has to force-shutdown the machine. That is at least the
case on Ubuntu 14.04 (and was on 12.04) with lowlatency kernel. Trying
to do sudo killall -9 jackd makes no difference. Essentially, it is
impossible to destroy the process and reboot hangs because of it.
Any idea what can be done to minimize this problem or alleviate it
altogether?
Best,
Ico
a workaround is from a terminal type:
pidof jackd
you'll get a number such as 3772
then type
kill -9 3772
18 Oct
18 Oct
1:22 a.m.
The process in question is jackd, and once this stuck state is reached one
cannot even start a new instance of jack which leads me to believe this is
a jack issue, particularly considering this is not a problem on Ubuntu
12.04 where you could still kill the process under these circumstances,
even though I still don't think allowing jack to get stuck like this is the
best approach to dealing with an issue like this, however unlikely it may
be. Now, it may be a case of bad packaging or some out-of-date version,
but given the circumstances I'm not convinced this is an alsa issue at this
point in time.
--
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
ico(a)vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
Ico.bukvic.net
On Oct 17, 2015 2:44 PM, "Fons Adriaensen" <fons(a)linuxaudio.org> wrote:
On Sat, Oct 17, 2015 at 07:24:02PM +0100, Will Godfrey
wrote:
On Sat, 17 Oct 2015 13:58:37 -0400
Ivica Ico Bukvic <ico(a)vt.edu> wrote:
That's what killall or pkill will do anyway, so
I don't think this is a solution.
I also don't think that Jack is involved. You'd
probably get the same effect when unplugging the
USB device while some ALSA app is using it.
There is a similar problem with the hdsp-madi module,
and it has hit me a number of times when installing
the card in a new system. Apparently the default
configuration expects an external clock, and when
that isn't connected any process that uses the device
hangs and can't be killed. The first process to do so
will be alsactl, called as part of the boot sequence.
And since that will be called again as part of reboot
or poweroff, those will hang as well. The only thing
you can do to pull the power plug, remove the card,
boot, edit the file used by alsactl, switch off, put
the card back and boot.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
Hi all,
This is a long-standing problem. While it is not intentional, sometimes
newcomers to jack on Linux tend to pull out the soundcard (USB) before
shutting down jack. This results in jack permanently hanging to the
point where one has to force-shutdown the machine. That is at least the
case on Ubuntu 14.04 (and was on 12.04) with lowlatency kernel. Trying
to do sudo killall -9 jackd makes no difference. Essentially, it is
impossible to destroy the process and reboot hangs because of it.
Any idea what can be done to minimize this problem or alleviate it
altogether?
Best,
Ico
a workaround is from a terminal type:
pidof jackd
you'll get a number such as 3772
then type
kill -9 3772
9:27 a.m.
On Sat, Oct 17, 2015 at 09:21:58PM -0400, Ivica Bukvic wrote:
The process in question is jackd, and once this stuck
state is reached one
cannot even start a new instance of jack which leads me to believe this is
a jack issue,
If a process can't be killed it must be stuck somewhere in
kernel/driver space where signals can't reach it (they will
be checked on return to user space). Since Jack has no kernel
space code itself, it would seem the problem is not within
Jack.
Anayway this is easy to test: instead of Jack, run e.g.
jaaa -A on the same USB device and then unplug it.
Another simple test: when Jack is stuck by unplugging
the USB device can you run Jack using another device
(and using a different server name of course) ?
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
17 Oct
17 Oct
6:50 p.m.
On Sat, 17 Oct 2015, Ivica Ico Bukvic wrote:
This is a long-standing problem. While it is not
intentional, sometimes
newcomers to jack on Linux tend to pull out the soundcard (USB) before
shutting down jack. This results in jack permanently hanging to the
Just one more reason why USB Audio Interfaces are not a good replacement
for PCI(e) Audio Interfaces. USB devices seem to randomly vanish without
anyone touching the plug even. My 10 year old PCI AI is more stable (and
can do lower latency) than any USB device I have tried yet.
Even my USB qwerty keyboard comes and goes sometimes.
--
Len Ovens
www.ovenwerks.net
7:17 p.m.
* Len Ovens <len(a)ovenwerks.net> [2015-10-17 14:50]:
On Sat, 17 Oct 2015, Ivica Ico Bukvic wrote:
I have no such problems at all
with my UA-25 usb interface, it is more
stable than my PCI HDSP card in fact, so ymmv.
This is a long-standing problem. While it is not
intentional, sometimes
newcomers to jack on Linux tend to pull out the soundcard (USB) before
shutting down jack. This results in jack permanently hanging to the
Just one more reason why USB Audio Interfaces are not a good replacement for
PCI(e) Audio Interfaces. USB devices seem to randomly vanish without anyone
touching the plug even. My 10 year old PCI AI is more stable (and can do
lower latency) than any USB device I have tried yet.
Even my USB qwerty keyboard comes and goes sometimes.
Ah! I had that and had to
look into usb autosuspend / laptop-mode-tools
which drove me crazy losing my mouse and keyboard sometimes.
9:20 p.m.
On Sat, 17 Oct 2015 15:19:06 -0400, Peter P. wrote:
laptop-mode-tools
Yes, a mouse needs to be waked up manually every 3 seconds before you
can use it, but green drives still get waked up automatically, when they
should stay asleep. Power management is broken for Linux. Developers of
the not bloated environments pay attention, but those of the bloated
environments blame hardware vendors. However, it's not the hardware,
it's usually Linux bloatware that causes power management issues.
Getting rid of crappy Linux software and installing the good Linux
software solves such issues. However, energy-saving tools for laptops
shouldn't be installed when using the computer for real-time audio.
Regards,
Ralf
18 Oct
18 Oct
1:16 a.m.
I wouldn't call that broken but rather conservative in terms of power
savings which is what many of us prefer to have on mobile platforms to
extend battery life under normal circumstances. Besides, disabling power
saving on specific devices is a simple editing of one configuration file
and adding modules you do not wish to suspend at any time.
Back on topic, which is why is jack hanging so badly that you cannot even
kill the process and what could be the solution. In other words,
alternatives to an USB audio interface are not an option, and under these
circumstances is this a case of poor packaging on Ubuntu's part, flaw in
jack's design and if so is there an intention intend to fix this in some
way by providing checks and balances within jack in case sound card
disappears, or is this kernel/alsa/driver issue--in this case it is a
lowlatency kernel. I'm not sure if I mentioned this in my original email
but this is on 64bit Ubuntu 14.04. Jack devs, I would love to hear from
you. Thank you.
--
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
ico(a)vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
Ico.bukvic.net
On Oct 17, 2015 5:20 PM, "Ralf Mardorf" <ralf.mardorf(a)alice-dsl.net>
wrote:
On Sat, 17 Oct 2015 15:19:06 -0400, Peter P. wrote:
laptop-mode-tools
Yes, a mouse needs to be waked up manually every 3 seconds before you
can use it, but green drives still get waked up automatically, when they
should stay asleep. Power management is broken for Linux. Developers of
the not bloated environments pay attention, but those of the bloated
environments blame hardware vendors. However, it's not the hardware,
it's usually Linux bloatware that causes power management issues.
Getting rid of crappy Linux software and installing the good Linux
software solves such issues. However, energy-saving tools for laptops
shouldn't be installed when using the computer for real-time audio.
Regards,
Ralf
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
5:58 a.m.
On 10/18/2015 03:16 AM, Ivica Bukvic wrote:
Back on topic, which is why is jack hanging so badly
that you cannot even
kill the process and what could be the solution. In other words,
alternatives to an USB audio interface are not an option, and under these
circumstances is this a case of poor packaging on Ubuntu's part, flaw in
jack's design and if so is there an intention intend to fix this in some
way by providing checks and balances within jack in case sound card
disappears, or is this kernel/alsa/driver issue--in this case it is a
lowlatency kernel. I'm not sure if I mentioned this in my original email
but this is on 64bit Ubuntu 14.04. Jack devs, I would love to hear from
you. Thank you.
Inserted a USB audio interface on my notebook and started JACK. Pulling
out the USB interface while JACK was still running froze the whole
notebook. I'd say that's not primarily a JACK issue, something at a
lower level probably goes wrong (Ubuntu 14.04, Jack2, kernel
3.16.0-50-generic).
Jeremy
5:53 a.m.
On 10/17/2015 08:49 PM, Len Ovens wrote:
Just one more reason why USB Audio Interfaces are not a good replacement
for PCI(e) Audio Interfaces.
USB devices support hot plugging, most if not all PCI audio interfaces
don't. To write off USB because sometimes the hot plugging functionality
fails doesn't seem fair to me.
Jeremy
2:24 p.m.
On Sun, 18 Oct 2015, Jeremy Jongepier wrote:
On 10/17/2015 08:49 PM, Len Ovens wrote:
Sorry, I was not trying to say USB Audio had no place, but rather that it
did not replace the PCI(e) AI. I should have said that. There are still
things that the "Internal" AI is better for.
USB hot plug _can_ work with jack:
http://gareus.org/blog/jack2dbus
--
Len Ovens
www.ovenwerks.net
Just one more reason why USB Audio Interfaces are not a good replacement
for PCI(e) Audio Interfaces.
USB devices support hot plugging, most if not all PCI audio interfaces
don't. To write off USB because sometimes the hot plugging functionality
fails doesn't seem fair to me. 
2:31 p.m.
On Sun, Oct 18, 2015 at 10:23 AM, Len Ovens <len(a)ovenwerks.net> wrote:
USB hot plug _can_ work with jack:
http://gareus.org/blog/jack2dbus
right. if the software notices signals on D-bus that the device is going
away, then it stops using it in a way that causes ALSA to get locked up,
putting the process into an un-killable state.
it would be nice if ALSA could be fixed to not do this, but it would also
be nice if key software like JACK would pay attention to device state
information too.
19 Oct
19 Oct
8:55 p.m.
On 10/18/2015 10:31 AM, Paul Davis wrote:
On Sun, Oct 18, 2015 at 10:23 AM, Len Ovens <len(a)ovenwerks.net
<mailto:len@ovenwerks.net>> wrote:
USB hot plug _can_ work with jack:
http://gareus.org/blog/jack2dbus
right. if the software notices signals on D-bus that the device is
going away, then it stops using it in a way that causes ALSA to get
locked up, putting the process into an un-killable state.
it would be nice if ALSA could be fixed to not do this, but it would
also be nice if key software like JACK would pay attention to device
state information too.
Since former is not necessarily in our immediate control, any hope of
latter being implemented by those on this list who are in control?
Best,
Ico
20 Oct
20 Oct
2:09 a.m.
On Mon, Oct 19, 2015 at 4:55 PM, Ivica Ico Bukvic <ico(a)vt.edu> wrote:
On 10/18/2015 10:31 AM, Paul Davis wrote:
On Sun, Oct 18, 2015 at 10:23 AM, Len Ovens <len(a)ovenwerks.net> wrote:
well, jack2 will listen to dbus already (see the link to robin's work on
this). jack1 is never going to interact directly with d-bus in the same way
as jack2, but for this particular purpose, a platform centric patch would
be smart.
better yet though, this should be buried inside the ALSA backend and all
backends should have a way to tell JACK that the device has "gone
away".we've had to visit+revisit this for the new abstracted audio I/O
backends inside ardour already.
chances of any of the usual suspects doing this for JACK1: close to zero i
think.
USB hot plug _can_ work with jack:
http://gareus.org/blog/jack2dbus
right. if the software notices signals on D-bus that the device is going
away, then it stops using it in a way that causes ALSA to get locked up,
putting the process into an un-killable state.
it would be nice if ALSA could be fixed to not do this, but it would also
be nice if key software like JACK would pay attention to device state
information too.
Since former is not necessarily in our immediate control, any hope of
latter being implemented by those on this list who are in control?
3:12 a.m.
On 10/19/2015 10:09 PM, Paul Davis wrote:
Since former is not necessarily in our immediate control, any hope of
latter being implemented by those on this list who are in control?
well, jack2 will listen to dbus already (see the link to robin's work
on this). jack1 is never going to interact directly with d-bus in the
same way as jack2, but for this particular purpose, a platform centric
patch would be smart.
better yet though, this should be buried inside the ALSA backend and
all backends should have a way to tell JACK that the device has "gone
away".we've had to visit+revisit this for the new abstracted audio I/O
backends inside ardour already.
chances of any of the usual suspects doing this for JACK1: close to
zero i think.
Thanks for the clarification, Paul. I guess my parting question is what
has changed between Ubuntu 12.04 days and 14.04 that has made this so
much more problematic? Kernel? Alsa? Both?
3143
days inactive
3146
days old
linux-audio-user@lists.linuxaudio.org
18 comments
9 participants
participants (9)
-
Fons Adriaensen -
Ivica Bukvic -
Ivica Ico Bukvic
-
Jeremy Jongepier -
Len Ovens -
Paul Davis -
Peter P. -
Ralf Mardorf -
Will Godfrey