Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
I upgraded to 2.14.0-2, shut down and rebooted to load a new kernel,
sound working outside KDE but not inside KDE, reverted to earlier kernel,
problem persisted, downgraded to timidity 2.13.2-41+b1 and rebooted,
sound was again working in KDE although some sound settings had sound muted
on left channel.
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
Upgrading to timidity 2.14.0-3 and running
service timidity restart
worked, but I am at a loss as to why timidity could stop all sound working
in KDE plasma and not just software MIDI playback.
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
restarting pc, starting KDE plasma desktop - no sound in KDE plasma desktop
* What exactly did you do (or not do) that was effective (or
ineffective)?
service timidity restart
from within KDE plasma desktop
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
Doing further tests, if I downgraded from 2.14.0-2 to 2.13.2-41+b1 then did
service timidity restart
service lxdm restart
sound output in KDE plasma run from lxdm worked
if I upgraded back to 2.14.0-2 and did
service timidity restart
service lxdm restart
sound output in KDE plasma run from lxdm failed
*** End of the template - remove these template lines ***
Same problem here on Debian unstable with LXDE. It seems timidity is
claiming the sound device before PulseAudio can.
# fuser -v /dev/snd/*
USER PID ACCESS COMMAND
/dev/snd/controlC0: timidity 635 F.... timidity
/dev/snd/pcmC0D0p: timidity 635 F...m timidity
/dev/snd/seq: timidity 635 F.... timidity
/dev/snd/timer: timidity 635 f.... timidity
# systemctl stop timidity
# fuser -v /dev/snd/*
#
After logging in again as a regular user, pulseaudio daemon starts
again and now is able to claim the sound device. Now sound works again.
HTH,
Peter Nowee
Can confirm, i have the same exact issue. Solved it temporarily by stopping timiddity, and then running on the terminal "pulseaudio -k"
Forgive my ignorance, but I don't see what reasoning drove reducing this bug's severity. https://release.debian.org/testing/rc_policy.txt says "[A]n issue is release critical if it: [...] * makes unrelated software on the system (or the whole system) break". I was bitten by this bug today (in testing), and from my perspective, the timidity package broke (important, IMO) functionality of a suite of other unrelated packages. That seems to qualify for at least serious (and therefore RC) severity. Am I missing something? Thanks, Brendon
Hi, I can also confirm I'm affected by this and agree that the severity should be grave. It's not even trivial to debug where the problem comes from, I even wrongly filled a bug to the linux-image since it seems to be racy too, so sometimes (I guess if timidity starts too late in the boot sequence) it could work, and I was unlucky enough that when I rebooted with the previous kernel it worked.
Fully agree. Was also bitten by this bug and it cost me several hours of google debugging, since I normally don't worry about sound -- it has "just worked" for quite some time now. And kudos for all those who made that happen!
We believe that the bug you reported is fixed in the latest version of
timidity, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 901148@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Bastien Roucariès <bastien@portable-bastien-2018.roucaries.eu> (supplier of updated timidity package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Tue, 26 Jun 2018 11:01:52 +0200
Source: timidity
Binary: timidity timidity-interfaces-extra timidity-el timidity-daemon
Architecture: source
Version: 2.14.0-4
Distribution: unstable
Urgency: high
Maintainer: Debian QA Group <packages@qa.debian.org>
Changed-By: Bastien Roucariès <bastien@portable-bastien-2018.roucaries.eu>
Description:
timidity - Software sound renderer (MIDI sequencer, MOD player)
timidity-daemon - runs TiMidity++ as a system-wide MIDI sequencer
timidity-el - Emacs front end to Timidity++
timidity-interfaces-extra - TiMidity++ extra user interfaces
Closes: 870338 901148 901931
Changes:
timidity (2.14.0-4) unstable; urgency=high
.
* QA upload
* Suggest only daemon that is pulled by kde, breaking audio output.
(Closes: #901148, #901931).
* Bug fix: "CVE-2017-11546 CVE-2017-11547", thanks to
Salvatore Bonaccorso (Closes: #870338).
Checksums-Sha1:
78ca5a1269f93d3cf8fd8e97a2444284cf02725d 2292 timidity_2.14.0-4.dsc
6b88aa373b03b60b072982062c560606120ba22c 29388 timidity_2.14.0-4.debian.tar.xz
8863efda0d1b57b02ce2814f88e4311e7b2200c7 6058 timidity_2.14.0-4_source.buildinfo
Checksums-Sha256:
09715b028c287bcff44c72e39dc65280e7b59c64e220ef6fc86b2d475318ae0b 2292 timidity_2.14.0-4.dsc
188808d2c7737785cfe579f7fc6c220306c97c15e44fa768a0ee964b8d669660 29388 timidity_2.14.0-4.debian.tar.xz
f6712723db70f00e67b887e862240dd24951637ad05c725ba62ea19b05a0c121 6058 timidity_2.14.0-4_source.buildinfo
Files:
cbd22b09b8749c37942cbc129e6dfa7a 2292 sound optional timidity_2.14.0-4.dsc
83ee5b57055d7de6b8004a101028f336 29388 sound optional timidity_2.14.0-4.debian.tar.xz
968bd13f2af11ab61936e573dba4b7b7 6058 sound optional timidity_2.14.0-4_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEXQGHuUCiRbrXsPVqADoaLapBCF8FAlsyBjUACgkQADoaLapB
CF+iyw/+LsrWeb7oD+ga2PeXZT+NREslWvbjQ/9WISrxuSywXyxPP/n/Q1kSKgU3
nnvGmB1DPVSvjM7Pqm/1Hy8VS7N0CAcb5UskmbK8cEyXIic7P/LvFQOXKy9/2D7j
ooPaXnXswELXXTerkBgLVr+AMX5lHKIwpLHB8PifZWFWw9Es0iwtPRKlPKQ4mAHw
IWIeBy6dzNr4IlC90+unaNwZ5YUKsXeAFzsAcHZflaJkxudA/frneN+Dw4Uy9tKP
5FGZy78+NhsfTT3Kw62SGU6dOWp/FbTiOxWCQ9m6KVmalK0ZOGtOBfCSss5Ne6a4
EEYe+WU+4AYGf5OkbUqckG+KoRXIQ2tyG/2bSl8DtfuY14sS1dEYcn+pBTWBEvTf
1UA2aNQCxx0gBbpodbcIFhNmVf+Eu1wc6PzKl7/FA3gORCcrmoapnXgLV2mjMLMn
9ER86bUoR3wgnkrqXba8/y4Rn7qWoNrZNXouLR+IS4KJ7iB88BOyZIHBak/nEEVm
QNpOvrHOJsfFPNZZE4NRZFdU81EWb1UnYff3vNolHB3keuGd9vQelB77mLqLqt2H
PJytyHPCXEiFKC70w15mWysDCMUCJdkzShYOVNyRwsgMy7cvs6zEnV4qsb/jD1Ov
NXVImxyfwtrBoJVwxkMuh9olIjkph88IhLbqYybzy7OLkzh9W14=
=G8jr
-----END PGP SIGNATURE-----
I still experience the same issue, i can solve it by stopping timidity: systemctl stop timidity 2018-06-20 15:20 GMT-03:00 lugarci1 <lugarci2@gmail.com>:
Quack, Not sure to understand what the changelog says about the fix but I'm running 2.14.0-8 and still experiencing the problem. Randomly Timidity holds the sound card device before Pulseaudio and I have no sound. \_o<
Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** After a couple of weeks away I forgot that I had held off upgrading to timidity 2.14.0-2 and later, and spent several hours again trying to figure out why I could get sound from a virtual console but not from within a desktop. Still a problem here with 2.14.0-8. *** End of the template - remove these template lines ***
severity 901148 critical found 901148 2.14.0-8 thanks Hi, I just spend 1 hour of time debugging my sound playback to finally discover it was just the timidity package that get the sound device blocked. I raise the severity of this bug to critical because it clearly render other packages unusable starting by pulseaudio itself. Regards, Thomas Pierson
Same experience here. The first warning was the mute button LED on my Thinkpad X220 no longer lit when pressed. Initially I thought it might be a failure of pulseaudio's udev detection, but static configuration also provided negative results. Finally I found this bug, purged timidity, and as soon as the daemon was killed received a desktop notification of found device. Agreed. Cheers, Nicholas
Having been hit by this on Buseter Testing before, I did some
investigation. Here are my findings:
Conditions for this bug to appear are:
* timidity-daemon is installed
* timidity service (from the timidity-daemon package) is enabled or
timidity gets started by hand
* No midi device is provided by the kernel
Only if all of these these conditions are fulfilled at the same time,
this comes into effect.
A quick test on Stretch with the timidity service enabled did not reveal
the bug. However, timidity was not running after boot, and I didn't find
the reason why. After starting it by hand, pulseaudio got unusable, just
like it does on Buster. So my guess is that the bug was actually present
in Stretch, it just did not show due to timidity not starting properly
at boot.
A removal of timidity-daemon on affected systems is sufficient. It is
set to "Suggests" instead of "Recommends" with timidity as of 2.14.0-8,
so the majority of people who install games or music programs that pull
in timidity will no longer be affected.
People who will be affected are those that got timidity-daemon installed
in Stretch by the "Recommends" dep, and then upgraded to Buster. Even an
apt autoremove will keep timidity-daemon installed.
One way to escape this bug is to have a midi device available in the
system, which can also be snd_virmidi. But I don't consider this a clean
solution, because it will probably interfere for people who have real
midi hardware.
What other options do we have? Simply keep it as-is and document it in
the the upgrade manual? Or do we have some mechanism available that
would remove timidity-daemon if it was installed automatically? Any
other ideas?
Hi Bastien, Could you have a look at this bug (in particular) the mail below. The bug has been tagged buster-ignore, but we would still like a more user-friendly solution (even if just in the form of a NEWS entry, so upgrading people are not caught unaware). Thanks, ~Niels
Hi, I'm still affected by this (must close timidity and restart pulseaudio after a reboot), and judging from the comment https://superuser.com/questions/1312163/dummy-output-instead-of-audio-device-on-debian-9/1346784?noredirect=1#comment2168375_1346784 I'm not the only person affected. So afaict the bug is still present.
Hi, This affects me too after I upgraded to Buster. The Superuser link Antoine Amarilli is giving suggests that timidity is started at system level, while pulseaudio is started at the user level. Maybe you could change that behaviour? Best
Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** I upgraded from Stretch to Buster and sound completely disappeared. Removing Timidity fixed the problem but made me unable to use gnu solfege as it depends on timidity. *** End of the template - remove these template lines ***
Hi Alain, The sound is broken by timidity-daemon, not the timidity package itself. So you should try to install GNU Solfege and check that timidity-daemon is not installed (timidity "suggests" timidity-daemon so it should not be installed automatically). Best, François
After many tests I have found the solution about the bugs around timidity-daemon and pulseaudio. timidity-daemon installs an system-wide daemon. But pulseaudio is a user-wide "daemon". With my appended patch the system-wide daemon will be removed and a xdg/autostart script will be installed. After that timidity together with pulseaudio runs perfectly.--- Have a nice day. Joachim (Germany)
Now I have made new Debian packages for buster and testing: https://www.joonet.de/sources/timidity/ Please test these package. All should be fine.--- Have a nice day. Joachim (Germany)
Now I have made new Debian packages for buster and testing including my patch: https://www.joonet.de/sources/timidity/--- Have a nice day. Joachim (Germany)
Am 01.12.20 um 18:53 schrieb Elimar Riesebieter: Yes - timidity is the reason. Thank you very much! Stopping timidity activates the intern sound. I have no idea when timidity is used, but i installed the packages https://www.joonet.de/sources/timidity/debian_buster/timidity_2.14.0-9~bpo10u1_amd64.deb https://www.joonet.de/sources/timidity/debian_buster/timidity-daemon_2.14.0-9~bpo10u1_all.deb This fixed the problem and the sound is working now. This bug should be moved to timidity, it is not a problem of ALSA. Best regards karsten
forcemerge 972689 901148 Hello together, inspired from this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935081 i tried the same on the Desktop PC with the problems in this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972689 Stopping timidity reactivates the sound in pulseaudio! But after installing the packages from joachim there where 2 instances of timidity after boot: timidity 791 1 0 15:45 ? 00:00:00 /usr/bin/timidity -Os -iAD karsten 2603 1 0 15:48 ? 00:00:00 /usr/bin/timidity -iA -Os I deactivated the system start of timidity with rcconf and now everything is fine. This modifications must be part of the distributions. Best regards karsten
Hello Karsten, Karsten wrote on 2020-12-06 11:25: because of all this trouble with timidity-daemon I have started build new packages, at first for testing, but then for buster to fix these bugs. The maintainer will sponsor me. Please wait a few days.--- Have a nice day. Joachim (Germany)
I have tested the new packages now: https://www.joonet.de/sources/timidity/debian_buster/timidity_2.14.0-9~bpo10u1_amd64.deb https://www.joonet.de/sources/timidity/debian_buster/timidity-daemon_2.14.0-9~bpo10u1_all.deb All looks fine, the system daemon is deactivated and only the user daemon running. The sound is working. Cheers karsten