Re: No sound in one Debian 10 partition (and a debug script)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Tanu and all,
Here are the outputs of running pa-info in the good partition and in
the bad partition.
Hope this help, and sorry for taking ages (12 days?) to answer...
Cheers!
  Eduardo Ochs
  http://angg.twu.net/
  http://angg.twu.net/e/
  http://angg.twu.net/emacsconf2019.html
    (^ on "executable notes")

On Thu, 5 Mar 2020 at 05:27, Tanu Kaskinen <tanuk@xxxxxx> wrote:
>
> 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@xxxxxxxxxxxxxxxxxxxxx/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@xxxxxxxxxxxxxxxxxxxxx/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:
> >
> >   1) *** ALL HINTS AND SUGGESTIONS ARE WELCOME ***,
> >
> >   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
> start/stop/restart:
>
> 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:
> https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/blob/master/src/utils/pa-info
>
> --
> Tanu
>
> https://www.patreon.com/tanuk
> https://liberapay.com/tanuk
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Attachment: opainfo-bad-partition
Description: Binary data

Attachment: opainfo-good-partition
Description: Binary data

_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux