from vortexal@lemmy.ml to linux@lemmy.ml on 08 Apr 17:28
https://lemmy.ml/post/28305975
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 and undid my edit to the modprobe blacklist, as they were only done as a temporary solution and they are 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.
threaded - newest
What distro are you on?
I’m using the Cinnamon edition of Linux Mint 22.1. I was going to mention this in the post but I wasn’t sure if I needed to, seeing that this issue seems to be present in other distros as well and I’m not the only person to experience this issue with this sound card.
Mint 22 is on pipewire now. You need to get rid of pulseaudio, go with pipewire and the pipewire-pulse compat layer. I had major problems until I installed an upgraded Wireplumber to 0.5 from ppa:pipewire-debian/pipewire-upstream
After that, you may have further issues with your configuration, and I would start by looking at your syslog for errors indicating what might be happening.
I actually installed pulseaudio to fix this issue, pipewire is still installed it just doesn’t work for me anymore. I can try configuring pipewire and see if I can get it working again but I’m looking at the conf file and I have no idea how to configure it without breaking it further.
I think that installing pulseaudio + pipewire will be problematic, at least that’s what I’ve read. I recommend uninstalling pulseaudio, getting the PPA version of Wireplumber and reporting back with your outcomes. Make sure pipewire-pulse is installed
I have already uninstalled pulseaudio since I only installed it because pipewire stopped working and now neither of them are working. I have also already seen that pipewire-pulse was installed and it was actually running. But before I install that ppa, the last time I installed a ppa, I had to completely reinstall Linux Mint so I just want to make sure that that is actually an official version of wireplumber.
It is. I run mint 22.1 as well. The Mint team ended up with a pipewire version that was mostly contemporary but a Wireplumber version that was legacy. It made configuration a nightmare. Once I upgraded Wireplumber, I was able to actually configure it and all my problems went away
Ok, I installed it and restarted my computer (even though I said I’d wait until tomorrow) and everything is working again. Thank you.
Hellz f’ing yes, fellow penguin!! So glad I could help!
I kinda remember having similar issues years ago, when transitioning from Pulseaudio to Pipewire on Ubuntu based distros like PopOS.
A bad guess is that either pipewire-pulse and pipewire-alsa was missing or I changed wireplumber to the other thing. I am very unsure, but it was a huge mess to play around and constantly switch between pipewire and pulseaudio to test things.
I would like to just use pipewire, as it’s what was preinstalled in Linux Mint, so I have already removed pulseaudio. pipewire-pulse was already installed but pipewire-alsa wasn’t, so I’ve installed that and I’ve restarted pipewire and reloaded alsa but it’s still not working.
i stopped having such problems ever since i switched to wayland. i guess you could find the right configs and persist it with ALSA and PulseAudio config files
I tried looking into configuring alsa and pulseaudio but the only configuration they seem to have aren’t applicable to my issue. I would just switch to wayland but none of my currently preferred desktop environments have full wayland support.
sorry, i of course meant PipeWire, wayland has nothing to do with audio.
Ok well, pipewire is what’s pre-installed and as of now neither pipewire nor pulseaudio are working. I have already uninstalled pulseaudio, as I would like to just use what’s preinstalled if I can get it working again.
While it’s not the solution you’re looking for, you can always write a script for those commands, and have it run on each startup.
.
Shot in the dark here…
You said that blacklisting the module brought back your device, but not the sound. Is it possible that pulse is selecting the dummy as the default interface?
Before reloading alsa and restarting pulse - If you go into pavucontrol and change the input/output devices to your sound card, does the sound start working?
If that’s the case, then you should be able to edit your pulse config to force your audio device to be default, regardless of whether or not the dummy is present.
(No idea about the dummy device, sorry)
I restarted my computer to check and if I run pavucontrol after starting, the only audio device listed is the dummy device. So I don’t know if that’s possible.
Ah, ok. I guess I misunderstood.
I’m afraid I don’t have any other suggestions that haven’t already been made elsewhere in the thread.
Best of luck, and I hope you get it figured out.
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 pipewirehere) 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.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 filesspa.alsa: ‘front:0’: playback open failed: Device or resource busymod.adapter: 0x5794b3a2b2a0: can’t get format: Device or resource busyYeah actually looks like the same issue I had. Just uninstall fluidsynth with
apt remove fluidsynthand (probably) reboot, and see if that fixes it.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.
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 --failedto 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.
I’m not sure how long everything takes normally but systemd-udev-settle.service took over two minutes. When running it with --user the longest was xdg-desktop-portal.service, which took 6 seconds. The third command gives:
UNIT LOAD ACTIVE SUB DESCRIPTION ● casper-md5check.service loaded failed failed casper-md5check Verify Live ISO checksums ● systemd-udev-settle.service loaded failed failed Wait for udev To Complete Device Initialization ● vboxdrv.service loaded failed failed VirtualBox Linux kernel moduleAlso, no I did check and fluidsynth was the only thing removed. I think it did for some reason add some of Wine’s dependencies to autoremove but I’ll deal with those later.Yeah not sure about that. My guess is the casper-md5check is irrelevant, not sure why udev would be affected by installing/uninstalling audio stuff, and also not sure if that actually slows down your boot, my guess would be no. vboxdrv and virtualbox are probably also irrelevant.
I think I should have included
systemctl --user list-units --failedpreviously.Ok and that command doesn’t list anything.
I just saw you edit and I did just remove pulseaudio.
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 pulseand kill it with (probably) something likesystemctl --user stop pulseaudioor 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.For some reason the the “stop” command didn’t work as it thought pulseaudio wasn’t running but I was able terminate it through htop. Also, that didn’t work, it did restart pipewire but my normal audio devices are still missing and I still don’t have working audio. I did, just in case, also check the journalctl and fuser commands you gave me previously, and fuser still just lists pipewire and journalctl stil gives the same error messages as before.
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.
Ok, so a lot of them are old messages, none of the messages from this session are labeled as busy. I did just try logging out and back in and that was pretty much instantaneous, so whatever it was that caused my computer to boot slowly just effect the boot itself. But yeah, I tried restarting pipewire and everything related to it and it’s still just showing the dummy output device and audio isn’t working. Thanks for trying though.
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/…/how-to-enable-boot-messages-to-be…
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.
Ok, even though I said I’d wait until tomorrow, I decided to try it again. It seemed to boot more or less normally but I did try someone else’s suggestion and it got audio working again. I did undo the edit I made to the modprobe blacklist and I did keep fluidsynth and pulseaudio uninstalled but I tried using the wireplumber ppa, like someone else suggested and my audio is working again. Granded, I have no idea what actually fixed the issue, so I don’t know who to fully credit but thanks for helping.
Glad you got it working.
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.
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… pipewireI know pulseaudio is only running because I manually ran it, so could it be wireplumber that’s causing the issue?
I mean it’s definitely weird that wireplumber and pulseaudio are running simultanously, that is probably not great (or maybe it’s harmless, idk), but it’s normal when using pipewire to have wireplumber on control0.
Anyway you should try running fuser before you apply your fix.
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.
If it’s just a matter of pulse selecting the wrong device I also had that issue and was able to work around it by adding a line to the end of my: /etc/pulse/default.pa
set-card-profile alsa_card.pci-0000_0e_00.3 output:analog-stereo+input:analog-stereo
You can get the correct name for your device with: pacmd list-sinks
While I have already found a working solution, I think the issue wasn’t that it was selecting the wrong device. it was almost as if my normal audio devices didn’t exist for some reason because nothing could see them, even my input devices were missing.
Use PipeWire instead.
I am, wireplumber is part of pipewire.