Bug#905774: jackd2: jackd no longer starts, since device is already in use; but who's using it?
On Thu, 09 Aug 2018 19:34:52 +0200 Jonas Smedegaard wrote: > Quoting Francesco Poli (2018-08-09 19:07:50) [...] > > All this makes perfectly sense: timidity pulled timidity-daemon by > > recommendation. Moreover recently, the recommendation has been turned > > into a suggestion. > > If I am not mistaken about english grammar... > > either it "perfectly makes sense" or it "makes perfect sense" > I think you're right, thanks for correcting me! > > > > OK, this leaves me with the need to understand why package "timidity" > > is installed on that machine, while it is not on the other similar > > one. I am pretty sure I haven't installed timidity by hand... > > I cannot tell how your system specifically ended in that state, but > timidity historically got auto-installed frequently (to me) like this: > > $stuff → libsdl-mixer1.2 → freepats → timidity > > My guess is that somehow (e.g. by using aptitude back when it had its > own its own independent tracking of auto-installed packages which then > got merged when APT grew support for that - I experienced some loss of > flags during that period) your system lost the auto-install flag for > timidity-daemon, keeping it around beyond removal of other packages and > package relationships getting relaxed. It could be, except that timidity-daemon still had the auto-install flag and timidity has it as well... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp_UYBZtK_4T.pgp Description: PGP signature
Bug#905774: jackd2: jackd no longer starts, since device is already in use; but who's using it?
Quoting Francesco Poli (2018-08-09 19:07:50) > On Thu, 09 Aug 2018 17:38:54 +0200 Jonas Smedegaard wrote: > > > Quoting Francesco Poli (2018-08-09 16:04:07) > [...] > > > I still have to understand why I had timidity-daemon installed on > > > that box: aptitude logs show that it had been there since long ago > > > (the oldest log shows an UPGRADE, rather than an INSTALL), but I > > > am sure I have never installed it manually. Indeed it was marked > > > as automatically installed, but no other installed package > > > currently depends on or recommends it. > > > On another machine with an almost identical list of manually > > > installed packages, I do not have timidity or timidity-daemon > > > installed... > > > > timidity used to recommend timidity-daemon (and some uses of APT > > wrongly flag auto-installed packages as manually-installed, or miss > > flagging them as auto-installed, or somesuch). Seemingly relaxation > > from recommends to suggests happened at release 2.14.0-4. > > Hello Jonas! > Thanks for commenting on this bug log. > > All this makes perfectly sense: timidity pulled timidity-daemon by > recommendation. Moreover recently, the recommendation has been turned > into a suggestion. If I am not mistaken about english grammar... either it "perfectly makes sense" or it "makes perfect sense" > OK, this leaves me with the need to understand why package "timidity" > is installed on that machine, while it is not on the other similar > one. I am pretty sure I haven't installed timidity by hand... I cannot tell how your system specifically ended in that state, but timidity historically got auto-installed frequently (to me) like this: $stuff → libsdl-mixer1.2 → freepats → timidity My guess is that somehow (e.g. by using aptitude back when it had its own its own independent tracking of auto-installed packages which then got merged when APT grew support for that - I experienced some loss of flags during that period) your system lost the auto-install flag for timidity-daemon, keeping it around beyond removal of other packages and package relationships getting relaxed. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#905774: jackd2: jackd no longer starts, since device is already in use; but who's using it?
On Thu, 09 Aug 2018 17:38:54 +0200 Jonas Smedegaard wrote:
> Quoting Francesco Poli (2018-08-09 16:04:07)
[...]
> > I still have to understand why I had timidity-daemon installed on that
> > box: aptitude logs show that it had been there since long ago (the
> > oldest log shows an UPGRADE, rather than an INSTALL), but I am sure I
> > have never installed it manually. Indeed it was marked as
> > automatically installed, but no other installed package currently
> > depends on or recommends it.
> > On another machine with an almost identical list of manually installed
> > packages, I do not have timidity or timidity-daemon installed...
>
> timidity used to recommend timidity-daemon (and some uses of APT wrongly
> flag auto-installed packages as manually-installed, or miss flagging
> them as auto-installed, or somesuch). Seemingly relaxation from
> recommends to suggests happened at release 2.14.0-4.
Hello Jonas!
Thanks for commenting on this bug log.
All this makes perfectly sense: timidity pulled timidity-daemon by
recommendation. Moreover recently, the recommendation has been turned
into a suggestion.
OK, this leaves me with the need to understand why package "timidity" is
installed on that machine, while it is not on the other similar one.
I am pretty sure I haven't installed timidity by hand...
And indeed it's marked as automatically installed:
$ aptitude search timidity
i A timidity- Software sound renderer (MIDI
sequencer, M
p timidity-daemon - runs TiMidity++ as a system-wide MIDI
sequ
p timidity-el - Emacs front end to Timidity++
p timidity-interfaces-extra - TiMidity++ extra user interfaces
Why is it there?
$ aptitude why timidity
i fluid-soundfont-gm Suggests timidity
This cannot be the actual reason, because a suggestion is too weak a
relationship, and aptitude should propose to purge timidity as unused
package, whenever I issue my routine upgrade command
("aptitude update && aptitude --purge-unused safe-upgrade").
It cannot be a dependence, since aptitude is more than willing to purge
timidity, if I ask it to do so:
$ aptitude -s --purge-unused purge timidity
The following packages will be REMOVED:
timidity{p}
0 packages upgraded, 0 newly installed, 1 to remove and 4 not upgraded.
Need to get 0 B of archives. After unpacking 1,582 kB will be freed.
Note: Using 'Simulate' mode.
Do you want to continue? [Y/n/?]
Hence, it must be a recommendation, maybe.
Let's search:
$ grep-aptavail -F Recommends timidity -s Package
Package: ecasound
Package: mma
Package: openttd
Package: pianobooster
Package: python-pykaraoke
Package: soundkonverter
Package: tk707
Package: wammu
But I don't have any of these packages installed:
$ apt policy \
$(grep-aptavail -F Recommends timidity -s Package \
| awk -F: '{ print $2 }') | grep Installed
WARNING: apt does not have a stable CLI interface. Use with caution in
scripts.
Installed: (none)
Installed: (none)
Installed: (none)
Installed: (none)
Installed: (none)
Installed: (none)
Installed: (none)
Installed: (none)
Real mystery...
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
. Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpeXkxm1XmIe.pgp
Description: PGP signature
Bug#905774: jackd2: jackd no longer starts, since device is already in use; but who's using it?
Quoting Francesco Poli (2018-08-09 16:04:07) > On Thu, 9 Aug 2018 13:22:55 +0200 Klaumi Klingsporn wrote: > > > Am / On Thu, 09 Aug 2018 12:35:28 +0200 > > schrieb / wrote "Francesco Poli (wintermute)" > > : > > > > > Why my jackd does not tell me which application is using > > > hw:0 ?!? How can I figure out which application is > > > getting in the way? [...] > > And than there's debian bug #901931 which gave me the same > > problem last time: timidity-daemon 2.14.0-3 blocked the > > sound-device (even for pulseaudio). > > Bingo! > After purging timidity-daemon, everything works again! > > I still have to understand why I had timidity-daemon installed on that > box: aptitude logs show that it had been there since long ago (the > oldest log shows an UPGRADE, rather than an INSTALL), but I am sure I > have never installed it manually. Indeed it was marked as > automatically installed, but no other installed package currently > depends on or recommends it. > On another machine with an almost identical list of manually installed > packages, I do not have timidity or timidity-daemon installed... timidity used to recommend timidity-daemon (and some uses of APT wrongly flag auto-installed packages as manually-installed, or miss flagging them as auto-installed, or somesuch). Seemingly relaxation from recommends to suggests happened at release 2.14.0-4. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#905774: jackd2: jackd no longer starts, since device is already in use; but who's using it?
On Thu, 9 Aug 2018 13:22:55 +0200 Klaumi Klingsporn wrote: > Am / On Thu, 09 Aug 2018 12:35:28 +0200 > schrieb / wrote "Francesco Poli (wintermute)" > : > > > Why my jackd does not tell me which application is using > > hw:0 ?!? How can I figure out which application is > > getting in the way? > > Maybe because jackd doesn't know about them? What do you mean? Does jackd only check for a list of applications known to lock the soundcard resource, and otherwise spit a more vague error message?!? > Top maybe the tool of your choice! Well, top(1) shows all the running processes, in descending order of resource (CPU, memory, ...) occupation. Does it have an option or command to show which process is using the soundcard? I failed to find any... > > > Please help me to investigate > > Only two guesses: pulseaudio may block your device. Try > > pulseaudio -k > > before starting jackd. This cannot be the case, since pulseaudio is not installed. > > And than there's debian bug #901931 which gave me the same > problem last time: timidity-daemon 2.14.0-3 blocked the > sound-device (even for pulseaudio). Bingo! After purging timidity-daemon, everything works again! I still have to understand why I had timidity-daemon installed on that box: aptitude logs show that it had been there since long ago (the oldest log shows an UPGRADE, rather than an INSTALL), but I am sure I have never installed it manually. Indeed it was marked as automatically installed, but no other installed package currently depends on or recommends it. On another machine with an almost identical list of manually installed packages, I do not have timidity or timidity-daemon installed... But anyway, thanks a lot for your really prompt and helpful reply! I wish I could get this positive experience every time I report a bug! ;-) Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp35wCChFLxP.pgp Description: PGP signature
Bug#905774: jackd2: jackd no longer starts, since device is already in use; but who's using it?
Am / On Thu, 09 Aug 2018 12:35:28 +0200 schrieb / wrote "Francesco Poli (wintermute)" : > Why my jackd does not tell me which application is using > hw:0 ?!? How can I figure out which application is > getting in the way? Maybe because jackd doesn't know about them? Top maybe the tool of your choice! > Please help me to investigate Only two guesses: pulseaudio may block your device. Try pulseaudio -k before starting jackd. And than there's debian bug #901931 which gave me the same problem last time: timidity-daemon 2.14.0-3 blocked the sound-device (even for pulseaudio). Klaumi --- Klaus-Michael Klingsporn mail: klaumi...@gmx.de web: www.klaumikli.de
Bug#905774: jackd2: jackd no longer starts, since device is already in use; but who's using it?
Package: jackd2 Version: 1.9.12~dfsg-2 Severity: important Hello, a couple of weeks ago I began experiencing an awkward behavior of jackd on one of my Debian testing machines (I run jackd with almost identical configuration on two other boxes, without issues). Basically, jackd no longer wants to start at the beginning of my X session and also refuses to start, when I try to start it manually from an xterm with: $ jackd --realtime -d alsa --device hw:0 \ --softmode --hwmeter --rate 44100 & The output I get is: jackdmp 1.9.12 Copyright 2001-2005 Paul Davis and others. Copyright 2004-2016 Grame. Copyright 2016-2017 Filipe Coelho. 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|44100|0|0|nomon|hwmeter|soft-mode|32bit ATTENTION: The playback device "hw:0" is already in use. Please stop the application using it and run JACK again Released audio card Audio0 audio_reservation_finish Cannot initialize driver JackServer::Open failed with -1 Failed to open server [1]+ Exit 255jackd --realtime -d alsa --device hw:0 --softmode --hwmeter --rate 44100 OK, so there's another application which is using hw:0 and won't release the resource. The problem is: which application is using hw:0 ?!? jackd does not tell me! The weird thing is that I searched the web and found some jackd output transcripts where jackd actually tells the user which application is using the soundcard with something like: ATTENTION: The playback device "hw:0" is already in use. The following applications are using your soundcard(s) so you should check them and stop them as necessary before trying to start JACK again: $APPLICATION (process ID $PID) See for instance http://www.tedfelix.com/linux/linux-midi.html Why my jackd does not tell me which application is using hw:0 ?!? How can I figure out which application is getting in the way? Please help me to investigate and please improve the usefulness of jackd error messages. Thanks for your time and for any help you may provide. Bye! -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages jackd2 depends on: ii coreutils 8.28-1 ii debconf [debconf-2.0] 1.5.69 ii libasound2 1.1.6-1 ii libc6 2.27-5 ii libdbus-1-31.12.10-1 ii libexpat1 2.2.5-3 ii libgcc11:8.2.0-1 ii libjack-jackd2-0 1.9.12~dfsg-2 ii libopus0 1.3~beta+20180518-1 ii libreadline7 7.0-5 ii libsamplerate0 0.1.9-2 ii libsndfile11.0.28-4 ii libstdc++6 8.2.0-1 ii python 2.7.15-3 ii python-dbus1.2.8-2+b1 Versions of packages jackd2 recommends: ii jackd2-firewire 1.9.12~dfsg-2 ii libpam-modules 1.1.8-3.7 ii qjackctl 0.5.0-1 Versions of packages jackd2 suggests: pn jack-tools pn meterbridge -- debconf information: * jackd/tweak_rt_limits: true
