[pulseaudio-discuss] No sound in one Debian 10 partition (and a debug script)

Tanu Kaskinen tanuk at iki.fi
Thu Mar 5 08:27:23 UTC 2020

On Tue, 2020-03-03 at 01:09 -0300, Eduardo Ochs wrote:
> Hi all,
> I have two Debian 10 partitions in my laptop, one that was a Debian 9
> that I "apt-get dist-upgrade"d to Debian 10, and one in which Debian
> 10 was installed from scratch using an installation pen drive...
> In the "dist-upgrade"d partition sound doesn't work and in the other
> one it does, so let me call them the "bad partition" and the "good
> partition".
> I was guessing that the problem was in ALSA, and to test that I wrote
> the script below, ran it in both partitions, and compared their
> outputs:
>   logthis () { echo $*:; eval $* 2>&1; echo; echo; }
>   {
>     # Debian version
>     logthis cat /etc/issue
>     logthis cat /etc/debian_version
>     logthis cat /etc/os-release
>     logthis lsb_release -da
>     logthis hostnamectl
>     # List devices and PCMs
>     logthis aplay -l
>     logthis aplay -L
>     # Drivers and modules
>     logthis "lspci -vvv | grep -A8 Audio"
>     logthis "lspci -knn | grep -A2 Audio"
>     # Permissions
>     logthis groups
>     logthis ls -lAF /proc/asound/
>     # This partition
>     logthis "mount | grep 'on / '"
>     # ALSA state
>     logthis "rm -f /tmp/o; /usr/sbin/alsactl -f /tmp/o store; cat /tmp/o"
>   } | tee ~/oalsa
> then I sent a long e-mail to the ALSA mailing list - this one:
>   https://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg32698.html
> I got two answers. This one, by Kaj Persson, about MANY other sound
> bugs in a dist-upgraded Debian 10,
>   https://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg32699.html
> and another one, very brief, in private - and possibly sent from a
> cell phone -, from Patrick May, saying that he thinks that "aplay -l"
> gives me "Subdevices: 0/1" in the bad partition and "Subdevices: 1/1"
> in the good partition because something - possibly pulseaudio - is
> using one of the subdevices, and that I should try "pulseaudio
> --kill"...
> I tried to test Patrick's suggestion, but I found that when I kill a
> pulseaudio process systemd starts a new one, and I spent about two
> hours trying to find a clean way to kill pulseaudio without systemd
> restarting it... I couldn't find a way, and the details overwhelmed
> me, and my brain overheated! Sorry!... =(
> If several people are having problems with sound on dist-upgraded
> Debian 10s - note that "several" at this moment means "at least two"!
> - then I think that it would be great to have a much bigger version of
> the script above that would also make pulseaudio report lots of things
> about its status. I can start working on that bigger script, but:
>   2) again: how do I kill pulseaudio? The most urgent thing now is to
>      add a block like this to the script:
>        logthis my-kill-pulseaudio
>        logthis aplay -l
>        logthis my-restart-pulseaudio

When PulseAudio is managed by systemd, it's best to use systemctl to

systemctl --user start/stop/restart pulseaudio.service pulseaudio.socket

It's necessary to list both pulseaudio.service and pulseaudio.socket,
because if you only stop the pulseaudio service, it will get
automatically restarted when an application connects to the socket.
When the socket is stopped too, PulseAudio won't restart automatically.

Regarding the "Dummy Output" problem you mentioned on alsa-user, the
usual reason is that something else is using the sound card, so
PulseAudio can't use it. On Debian it's quite often timidity (or at
least has been in the past, I would expect that problem to have been
fixed by now).

You can find out what applications are accessing the sound card with
"lsof /dev/snd/*".

You mentioned that it would be good to have a script that collects
information about PulseAudio status. Such script was added in
PulseAudio 13.0, and can be found here:



More information about the pulseaudio-discuss mailing list