Created attachment 140339 [details] Debian testing packages installed/upgraded/removed immediately before sound was lost After updating Debian testing today my sound completely broke. I have managed to fix the issue by enabling "module-alsa-sink" on "/etc/pulse/default.pa". Even as "module-udev-detect" found the card, for some reason it didn't create a sink for it, falling back to a null sink ("Dummy output") instead. Before that, I tried using "module-detect" instead of "module-udev-detect" and it did manage to find my cards and create a non-null sink but I still didn't get any sound. I think in all likelihood it was just using the wrong card because everything seemed to be working fine, except that I didn't get any actual audio from the connected ports. I'm using a HDA ATI SB card on a Realtek ALC887-VD chip on an old M5A78L-M LX/BR ASUS motherboard and since activating "module-alsa-sink" everything is working as intended. I'll updated this issue if anything else comes up. Pùlseaudio version is 11.1. This is my first time going into Pulseaudio to find a solution myself but since I did manage to resolve the problem I think I got a decent grasp on what is happening. I apologize if I'm making any wrong assumptions or writing nonsense. What is crazy is that the Debian upgrade I made today was fairly small and didn't touch any package that would obviously cause this issue. I will attach a list of the packages that changed (most stuff is just me removing Wine). The only things that I can imagine caused this issue were either "gstreamer1.0-plugins-ugly" (unlikely) or" libstdc++6" (equally unlikely but could explain an unexpected behavior change on udev-detect). Maybe I'm missing something so feel free to take a look at the apt log. Thanks for all the great work on Pulseaudio - other than this instance, it's been many years since I had any trouble at all :) (By the way, searching for "linux" "no sound" "dummy output" online shows a lot of hits if you filter only results from the past month, many with the same story of recent upgrade/install on a Debian-based distro. Probably same issue?)
At some point I did remove "~/.config/pulse/" as was suggested by my research and I noticed this caused PA to stop respawning its daemon automatically - but I didn't notice anything else that suggests cleaning this dir was an essential part of the fix.
After losing sound, I have booted my system on older kernels (as old as 4.15.0), which showed the same problem. Booting a live CD had the sound working fine. The problem started immediately after upgrading my system's packages so it's unlikely to be at all related to hardware, kernel, configuration, etc - as you can see by the apt log, nothing in that regard was changed much. Even though I can't say which package change caused the problem, I'm pretty sure one of them did.
I'm fairly confident that the timidity upgrade caused this. Quite a few people have recently had problems with timidity hogging the sound card, causing pulseaudio to not have access to the sound card.
There seems to be a Debian bug about this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901148
You are absolutely correct, removing Timidity and reverting my configuration file has things back to normal. I use Timidity fairly often but as a command-line tool for one of my projects and I had no idea that it had a daemon at all, sorry. That being said though, I still think this report could be acted on by having module-udev-detect print a big bold error when it tries to access a card that is being hogged by some other resource. Should I open a new report for this? I don't remember seeing any such message while browsing logs and could help a lot for all sorts of troubleshooting. I can reinstall timidity later on to make sure no such message is already being printed, but I'm fairly sure it isn't, or at least not as obviously as other error messages that do pop up on the logs... Thank you very much for reply and info, Tanu!
I submitted a patch for printing a warning when we encounter a busy sound card: https://patchwork.freedesktop.org/patch/232922/
Thanks a lot, Tanu! Let me ask: is a warning the sort of message that appears in bold when you are reading the logs through journalctl? Or only errors do that (by default, at least)? I'm happy that you agreed with my suggestion and went on to produce a patch, thanks again!
I tested how the warning shows up in journalctl, and unfortunately it has no highlighting. Making the warning an error wouldn't help, because the problem is that when pulseaudio is started by systemd, the logs go to stderr. The journal picks up the messages from stderr, but the journal has no idea about the importance of the messages. PulseAudio supports logging to the journal directly, but unfortunately that doesn't get enabled when PulseAudio is started by systemd. We could pass --log-target=journal on the command line that is specified in the .service file, but that would make it impossible to override the log target from daemon.conf, so some other solution is needed. I think it would be good to add a --started-by=foo command line option. If it's set to "systemd", we could then adjust the default log target based on that. The option would also provide useful information in "ps" output.
Created attachment 140835 [details] attachment-9381-0.html This issue is resolved now and too minor to trigger a reworking of the log system. My suggestions would be: 1. Do change the log message from a warning to an error regardless. Not being able to access the sound card is an error and an unexpected situation which will lead to other problems (as seen in the original complaint). 2. Your --started-by solution seems to be desirable on its own. I would suggest opening up a new bug report so that knowledgeable people can discuss the best solution to the current logging situation and then proceed to implement it. Hopefully the combination of the two might result in better logging to this particular problem but I think #2 is out of the scope for this particular issue and should be discussed on its own merits. On 29 June 2018 at 06:50, <bugzilla-daemon@freedesktop.org> wrote: > *Comment # 8 <https://bugs.freedesktop.org/show_bug.cgi?id=107037#c8> on > bug 107037 <https://bugs.freedesktop.org/show_bug.cgi?id=107037> from Tanu > Kaskinen <tanuk@iki.fi> * > > I tested how the warning shows up in journalctl, and unfortunately it has no > highlighting. Making the warning an error wouldn't help, because the problem is > that when pulseaudio is started by systemd, the logs go to stderr. The journal > picks up the messages from stderr, but the journal has no idea about the > importance of the messages. PulseAudio supports logging to the journal > directly, but unfortunately that doesn't get enabled when PulseAudio is started > by systemd. > > We could pass --log-target=journal on the command line that is specified in the > .service file, but that would make it impossible to override the log target > from daemon.conf, so some other solution is needed. I think it would be good to > add a --started-by=foo command line option. If it's set to "systemd", we could > then adjust the default log target based on that. The option would also provide > useful information in "ps" output. > > ------------------------------ > You are receiving this mail because: > > - You reported the bug. > >
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.