[solved] I'm having audio issues with Linux and while I have a temporary solution, I'd like to have a permanent solution if possible.
Final update (hopefully): It seems that I have been able to fix the issue. I'm not sure what exactly caused the problem but either removing fluidsynth or installing the wireplumber ppa fixed the issue and I have working audio again. I've also removed pulseaudio as I only installed it as a temporary solution and it's no longer necessary.
For the past three days, I've been having this issue where my computer starts with no audio and the only sound device listed is a "dummy output" device. I've tried looking online for solution but the only solution I found has to be redone manually every time I start/restart my computer. It also seems like this issue is common with and possibly specific to the sound card my computer has, which is an "Intel Sunrise Point-LP HD Audio".
The solution that worked for me was to add blacklist snd_soc_avs
to the modprobe blacklist and then run the two commands sudo alsa force-reload
and pulseaudio
. Adding snd_soc_avs to the blacklist permanently brought back my actually audio devices but it didn't fix the audio nor did it remove the dummy output device. The two commands I listed do restore the audio and remove the dummy output device but they only work for the current session and I have to run them again after starting/restarting my computer.
I have no problem doing this if there isn't a permanent solution but I would like a permanent solution, if possible.
gnuhaut
in reply to vortexal • • •I had an issue like this recently on Debian testing and it turns out fluidsynth was hogging the sound device and so pipewire couldn't open it. IDK why it was doing that all of a sudden. The symptom was also just having the dummy device.
I think what I did to figure this out was look at the pipewire logs and it said something to the effect that it couldn't open the sound device because it was busy, and according to my bash history I did
fuser -fv /dev/snd/*
and figured out it was fluidsynth that was using it, which I then disabled or maybe uninstalled because wtf do I need midi for anyway.Your problem may be different, but I can imagine, theoretically, that all the stuff you're doing makes it so pulseaudio gets first dibs on the (otherwise busy) sound device and so maybe you have misdiagnosed the problem.
vortexal
in reply to gnuhaut • • •When I run that command, I get:
$ fuser -fv /dev/snd/* USER PID ACCESS COMMAND /dev/snd/controlC0: j 2002 F.... wireplumber j 11734 F.... pulseaudio /dev/snd/seq: j 1998 F.... pipewire
I know pulseaudio is only running because I manually ran it, so could it be wireplumber that's causing the issue?
gnuhaut
in reply to vortexal • • •I mean it's definitely weird that wireplumber and pulseaudio are running simultanously, that is probably not great, but it's normal when using pipewire to have wireplumber on control0.
Also I deleted my original post, because I wasn't super happy about it, and made new one, so now there are two versions of this post. Sorry.
gnuhaut
in reply to vortexal • • •I mean something must have changed three days ago, kernel update maybe? You could try running a different kernel and see if this fixes it automagically.
I recently also had an issue where I could only see a dummy device, and that got me wondering. It was caused by fluidsynth hogging the audio device. So maybe could you check something? Look at the log file for pipewire (
journalctl --user -u pipewire
here) and dofuser -fv /dev/snd/*
when it's still in its broken state to see if (maybe) you're misdiagnosing the problem. Because I could possibly sort of imagine that doing the force-reload and start pulseaudio dance might actually have seemingly fixed my fluidsynth issue by inadvertently making it so that pulseaudio got a hold of the audio device.vortexal
in reply to gnuhaut • • •I thought that it was a kernel update too but the last time it was updated was two weeks ago and nothing else relevant to audio was updated either.
I've restarted my computer and the fuser command does show mutiple instances of fluidsynth. I also ran the journalctl command and I'm getting a bunch of the same error messages over and over again. They are:
mod.jackdbus-detect: Failed to receive jackdbus reply: org.freedesktop.DBus.Error.ServiceUnknown: The name org.jackaudio.service was not provided by any .service files
spa.alsa: 'front:0': playback open failed: Device or resource busy
mod.adapter: 0x5794b3a2b2a0: can't get format: Device or resource busy
gnuhaut
in reply to vortexal • • •apt remove fluidsynth
and (probably) reboot, and see if that fixes it.vortexal
in reply to gnuhaut • • •Nope, that didn't work. In fact, it made the issue worse because now I can't get audio to work at all because my normal audio devices are missing again. I also tried running the commands again and the journalctl command is still giving me the same error messages and fuser states that the only thing running is pipewire.
Also, for some reason, my computer took a longer time to boot than normal and it made me input my password at startup, which I have Linux Mint configured to just automatically log me in without it. So if you have any further suggestions that require a restart, I don't feel comfortable restarting my computer again and I will try them tomorrow.
gnuhaut
in reply to vortexal • • •Oh, I'm sorry. Can you run
systemd-analyze blame
(and alsosystemd-analyze --user blame
) and look for something, near the top, that took a long time? Alsosystemctl list-units --failed
to see if something has failed to load properly.I'm afraid to ask, and I should have thought of that, do you remember if uninstalling fluidsynth removed anything else?
Also maybe try uninstalling pulseaudio, it's possible it's fighting with pipewire over the device, but that's just a guess.
vortexal
in reply to gnuhaut • • •gnuhaut
in reply to vortexal • • •Oh good. Maybe you can try restarting pipewire w/o rebooting.
First, check if pulse is running (it might be even if uninstalled), with
systemctl --user list-units
(search for pulse by typing/pulse
) orps -A|grep pulse
kill it with (probably) something likesystemctl --user stop pulseaudio
or maybekillall pulseaudio
. Not sure what's better here, but it needs to be killed if it's running.Then do
systemctl --user restart pipewire pipewire-pulse wireplumber
.vortexal
in reply to gnuhaut • • •gnuhaut
in reply to vortexal • • •Yeah I wrote that stop command wrong, it's supposed to be
systemctl --user stop pulseaudio
. The relevant errors from journalctl were the "busy" errors. Are they still there? Maybe they're old messages? You can type G to go to the end of the log.Also, and this is probably my last suggestion, try restarting the socket with
systemctl --user restart pipewire-pulse.socket
. And maybe restart all the other crap as well for good measure. My theory here is that pulseaudio overwrote that socket with it's own socket, and anything trying to play sound would be trying to connect to the nonexistent pulseaudio, and maybe restarting pipewire doesn't actually recreate the socket, because systemd does that, but I'm not sure that's actually how that works.Theoretically logging out and in again should also restart all the things pipewire I think, but it's possible that whatever is slowing down your boot is actually slowing down the login, so do at your own risk.
vortexal
in reply to gnuhaut • • •gnuhaut
in reply to vortexal • • •If we assume, for a moment, that your issue was in fact related to fluidsynth, which I kinda still think it might be, because of what fuser and the logs showed, it would be a good idea to undo your module blacklist thingy and reboot.
If your slow boot issue persists, and you try to fix that tomorrow, then try looking at the bootup messages as described here:
askubuntu.com/questions/25022/…
If you reinstall pulseaudio to get back to where you were before, uninstall pipewire, those two shouldn't be running simultaneously.
Good luck and keep me updated if you manage to fix it somehow.
How to enable boot messages to be printed on screen during boot up?
Ask Ubuntuvortexal
in reply to gnuhaut • • •gnuhaut
in reply to vortexal • • •