Pulseaudio fails to detect sound card, while timidity is installed

I've changed the title because according to lspci the audio device is actually Intel Corporation Sunrise Point-LP HD Audio (rev 21)

Status changed to 'Confirmed' because the bug affects multiple users.

Can you please run this command:

  dpkg -l > dpkgl.txt

and send us the resulting file?

Result of:
dpkg -l > dpkgl.txt

Thanks! The problem is:

ii timidity-daemon 2.14.0-8 all runs TiMidity++ as a system-wide MIDI sequencer

which makes this a duplicate of bug 210472.

Please just uninstall timidity and timidity-daemon.

Same thing on a Lenovo L520 with Intel chipset, attaching some info just in case it helps.

I still have this problem in Ubuntu 19.04 develpment version. Here is a Debian bug about this:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901931

It doesn't appear Timidity is being maintained upstream anymore. If you can, please just uninstall it.

I do use it, to play midi files and to convert them to other formats. But if it is an abandoned project, I will have to look for alternatives.

Daniel, why do you say it is unmaintained? I see an active Debian maintainer:

https://tracker.debian.org/pkg/timidity

and in Sourceforge there is a new upstream version from October 2018.

OK, maybe just not with many releases or much active development. The latest version was released August 2018 and the latest commit was October 2018:

  https://sourceforge.net/p/timidity/git/ci/master/tree/

I was also thrown by the latest news item on the main project page being dated 2004 :)

  http://timidity.sourceforge.net/

But that may not mean anything... A mature project like Timidity might not _need_ any regular changes or releases.

My main concern with respect to this bug is that I can't find any way to report bugs upstream, other than these:

  https://sourceforge.net/projects/timidity/support

From the discussion in bug 210472 and in the Debian bug, it looks more like a configuration or intergration issue in timidity packages rather than a genuine upstream bug.

Also, forums and mailing lists are a way to report bugs, too. Even though not as convenient as bug trackers.

Does "fix release" mean this bug has been fixed?

It does not seem to have landed in ubuntu yet : https://changelogs.ubuntu.com/changelogs/pool/universe/t/timidity/timidity_2.14.0-8/changelog

I think that "Fix Released" status is misleading. Even the Debian bug mentions the problem is in 2.14.0-8 and that's the latest version in Ubuntu and Debian.

It looks like the Debian bug was closed prematurely without a fix being released. I was going to unlink it here but maybe not... Let's just be aware there was no "Fix Released".

Can the Debian bug be reopened? Otherwise, I'm afraid, we'll never see it fixed.

Try the user/group fix mentioned there first:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901931

If that works then we know what kind of fix to propose to Ubuntu or Debian.

If that doesn't work then please email <email address hidden> pointing out it is not fixed and to reopen the bug.

A user in that bug already verified that it works. What I'm pointing out is that the user/group fix is not implemented in the Debian or Ubuntu package, and as long as that bug is closed it's not likely become implemented.

I have tested on Kubuntu 19.04:

1. After installing timidity-daemon, the timidity user is automatically created and added to the audio group. After reboot, the primary audio output device is inaccessible in PulseAudio.
2. After removing timidity user from audio group and rebooting, PulseAudio is able to use all audio output devices, as expected. I don't know how to test whether timidity works.
3. Purging timidity-daemon and timidity packages does *not* remove the timidity user. So, if the packages were installed before, after purging the user stays in the system and in the audio group. You have to manually remove the user (either completely or just from the audio group) using deluser. I think, that the user stays in the system may be a bug on its own.

Sending email to <email address hidden> bounces because the bug is archived and cannot be modified.

I confirm that timidity works after removing the timidity user. So instead of removing timidity all together, another workaround for this bug is to remove the timidity user and make sure the audio group is empty.

I removed timidity (without even purging) and my sound satarted working normally, even though my audio group still contains two users: pulse and timidity. This group is supposed to be empty?

I reinstalled timidity and timidity-daemon and the problem returned. I removed timidity from the audio group and rebooted and the problem was again fixed. The timidity program works. (I don't know what the daemon does.)

I have unarchived / reopened and commented debian bug.

I upgraded from 18.04 to focal and had the same problem. Purging timidity got audio back for me as well.

In case this helps anybody:
I solved the MIDI issue by installing fluidsynth instead of timidity according to this guide:
https://blog.geierb.de/debian-fluidsynth-als-systemd-service/

What's missing though is the connection of fluidsynth server to pulsaudio DISPLAY.
you have to add DISPLAY=:0 to etc/default/fluidsynth

this was done on Kubuntu LTS 18.4

Started happening to me on upgrade from 18.04 LTS to 19.10.

KDE shows only "dummy" device, until

# sudo apt remove timidity-daemon
# pulseaudio -k && sudo alsa force-reload

and suddenly audio is back. I still have timidity itself installed

Hit this issue when upgrading from Kubuntu 18.04 to 20.04.

Solution was to "sudo apt purge timidity timidity-daemon" and the audio devices immediately were recognized by the system, didn't need to reboot.

This happened on a bog-standard 2015 era Intel-based laptop, nothing exotic.

On 20.04 at least it seems sufficient to only purge timidity-daemon and still timidity could be used to play midi files.

Managed to make TiMidity++ work together with PulseAudio just fine on Focal 20.04.1. The idea is just to start both pulseaudio and timidity under the same user. One-liner for the current desktop user:

sudo sed -E "s,^(SERVER_NAME)=(.*)$,\1=$(id --user --name $USER) #\2," -E "s,^(SERVER_GROUP)=(.*)$,\1=$(id --group --name $USER) #\2," -i /etc/default/timidity && sudo sed -E "s,^(\s*chown) timidity (/var/run/timidity)$,\1 "$SERVER_USER" \2," -i /etc/init.d/timidity && sudo systemctl daemon-reload && sudo systemctl stop timidity && sudo killall timidity; sudo systemctl start timidity && ps -o pid=,state=,command= -C timidity; systemctl status timidity; sudo systemctl restart pulseaudio; pacmd list-cards

One can replace $USER with any user name given PulseAudio starts under the same user as well, the user is a member of the respective groups, and it has sufficient permissions for both daemons.

TL;DR: It is enough to update the config of the timidity daemon instead of purging the timidity-daemon package in order to make pulseaudio work together with timidity daemon.

@h1bymask

Seems cleaner to share the audio group between the two daemon processes rather than trying to merge the two separate uids.

/etc/group already seems to do this (on 18.04):

    $ grep audio /etc/group
    audio:x:29:pulse,timidity

Given that the devices under /dev/snd/ are all read-write by group audio.

sudo setfacl -m u:user:rw /dev/snd/*

solved the problem as solution found on https://www.toolbox.com/tech/operating-systems/question/no-sound-at-all-in-lubuntu-1404-103114/ and somewhere on Ask ubuntu