Dear Maintainer,

   * What led up to the situation?
I installed Timidity.  It doesn't break until after a reboot (which may take
weeks for some people).  After I rebooted days later for an unrelated reason, I
lost all audio and PulseAudio no longer showed my sound card at all.
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
Researched online, found a 6 year old bug marked as CLOSED, and impemented the
fix by removing timidity from the
audio:
 line in /etc/group where it was put by timidity-daemon.postinst line 48 as
referenced in reply #58 HERE (ty Kingsley): https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=901931#58
   * What was the outcome of this action?
After removing timidity from the audio: line in /etc/group and rebooting, aduio
was restored and PulseAudio once again showed my sound card as present.
   * What outcome did you expect instead?
Bug #901931 to not have been marked as resolved and this to have been fixed SIX
YEARS ago.

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?

*** End of the template - remove these template lines ***

Hello,

According to what has been described it sounds like timidity (which I
don't even know what it is/does) uses alsa directly and happens
to be able to open the sound device before pulseaudio manages to grab
it.

From what I'm hearing I'm willing to argue that this is not even
necessarily a bug. This is how sound on linux works. You can only have
one process using the sound device at a time (unless you have fancy
soundblaster hardware which supports multiple streams at once). This is
why sound multiplexer daemons (like pulseaudio, esound, pipewire, etc.)
exists to begin with.

While in todays modern times we expect everything to go via these sound
multiplexers, but I'm not sure we can outright forbid software in the
debian archive from not doing so. This just seems like a
mis-configuration on the users part. (Any package in debian makes the
assumption that if you install it you want to use it. Thus timidity
behaves according to that. If you want to use pulseaudio instead, then
you should stop timidity (or possibly uninstall it if you don't need
it).)

Bug reports with release-critical severity is supposed to reference
the part of debian policy it violates. The "breaks unrelated software"
justification was used, but I don't see how that's applicable. Similarly
you could argue that any web server breaks all other web servers since
they all try to listen on port 80 in their default configuration and
only one of them can grab the port at a time. I doubt anyone would argue
that's a RC bug.

Hopefully there's a better default configuration timidity could use, but
that's not release-critical in my opinion.

Regards,
Andreas Henriksson