search

pop-os / pop

A project for managing all Pop!_OS sources
https://system76.com/pop
2.45k stars 87 forks source link

Audio randomly broken #1409

Open Yuri6037 opened 3 years ago

Yuri6037 commented 3 years ago

Distribution (run cat /etc/os-release): NAME="Pop!_OS" VERSION="20.10" ID=pop ID_LIKE="ubuntu debian" PRETTY_NAME="Pop!_OS 20.10" VERSION_ID="20.10" HOME_URL="https://pop.system76.com" SUPPORT_URL="https://support.system76.com" BUG_REPORT_URL="https://github.com/pop-os/pop/issues" PRIVACY_POLICY_URL="https://system76.com/privacy" VERSION_CODENAME=groovy UBUNTU_CODENAME=groovy LOGO=distributor-logo-pop-os

Related Application and/or Package Version (run apt policy $PACKAGE NAME): pulseaudio snd-hda-intel alsa-mixer gnome-control-center

Issue/Bug Description: Audio randomly gets broken and the correct device is deleted and a new buggy one with a weird name is created: "Digital Output (S/PDIF) - Built-in Audio". The correct device name should be "Line Out - Built-in Audio".

Steps to reproduce (if you know): Reboot computer again and again until the device gets deleted sometimes it comes back after launching gnome-control-center.

Expected behavior: Audio should never fail.

Other Notes: This has never occurred under PopOS 20.04. This only occured after upgrading to PopOS 20.10 but not right after upgrading as it worked for 2 weeks on 20.10. It just started to break today!

Computer specs:

Also when it decides to work there are two sound windows that opens when I press the sound controls on the keyboard, one on each screen. The main screen shows the bad one and the secondary screen shows the correct one.

WereDev commented 3 years ago

Today, I ran across a similar issue. Not sure if related. I'm running PopOs 20.10 and it was working great for weeks. Today I did did some system updates as Pop Shop likes to warn me about and immediately after, audio connections starting being very flakey, and I'm not sure which package broke it. The issues that I'm having is that audio devices will sometimes not be detected or will be detected incorrectly. I have two usb connected audio devices.

One is the headphone jack via a Dell WD19. The audio portion will either get detected and work ok, or it won't. Even when the audio isn't detected correctly, the monitor, mouse, and keyboard that I am using through the dock continue to work just fine.

The other is a Logitech G533 headset. This used to work great. Now sometimes it's not detected. Or it will detect it but let me select to use the microphone OR as audio out, but not both. Or sometimes it works.

I haven't yet figured out a pattern and even reboots, or power off/on doesn't seem to help the reliability of results.

The last update I did was on 1-Nov afterwhich everything worked fine. The issues started after running updates this afternoon; 19 Nov.

WereDev commented 3 years ago

Saw a reference to this in another post. I'll work through this and see if it can make my experience more reliable.

https://support.system76.com/articles/audio/

Yuri6037 commented 3 years ago

Thanks for the info, this fixed it but it only fixes it until reboot/poweroff...

It's not great to have to open a terminal then run systemctl --user restart pulseaudio on every reboot... It's a terrible experience especially when you have a meeting...

After removing the home .config/pulse folder, it seam the Line Out device seam to be a bit more stable but this does not change the fact that on every reboot, the default output device is almost never appropriately set back to the correct "Line Out". Sometimes there is a third device created called "Dummy Output".

EDIT: Do you know a way to blacklist the wrong device names?

WereDev commented 3 years ago

I finally managed to get some time to play with this. On a fresh boot, if I have issues with audio, systemctl --user restart pulseaudio does seem to rectify the problem. Subsequent reboots can bring the problem regardless of the other steps taken (clearing configs, etc). Each time, I was able to confirm that Alsa sees my headset fine, but PulseAudio seems hit or miss on what it sees. Sometimes it'll find the headphones, sometimes the microphone, sometimes both, sometimes neither. After the first use of the above command, subsequent issues sometimes require a reboot before Pulse works again. Trying that command or other steps outlined in that document don't seem to enable settings to be kept after a reboot and the problem will reappear.

WereDev commented 3 years ago

As a side note, systemctl --user restart pulseaudio also seems to crash gdm as my whole screen goes black and refreshes.

@Yuri6037 I sadly don't know how to remove dummy outputs. I'm still relatively new to linux and am learning as I go.

WereDev commented 3 years ago

My issue appears to be further reflected by other users on the PulseAudio support page.

https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1036

Seems like there is a known issue with version 13.99.2 which are potentially fixed in 13.99.3. Also saw that version 14 was released today, so hopefully those get included in a the popos repos soon so that we can update and try it.

WereDev commented 3 years ago

@Yuri6037 Re dummy devices, I came across this which appears to match what you're talking about. There's a potential work around in there that might work for you until we get an update pulseaudio from ubuntu. As a sad side note, looks like we might not get the updated pulseaudio until 21.04.

https://www.mail-archive.com/desktop-packages@lists.launchpad.net/msg648052.html

Yuri6037 commented 3 years ago

Thank you but the link you gave me describes a bug that isn't exactly my bug: pulseaudio -k doesn't fix anything in my case only the long command with systemctl seam to do something. Also in my case the device is not always "Dummy Output" it can be a different name. Sometimes I even get 3 devices: the dummy one, the wrong one and the correct one.

When running the systemctl command I don't have gdm crash but I already got 2 other problems: gnome control center crash (not a big deal) and once I got complete system lock up with no ssh, no xorg, nothing...

Edit: the first link is about usb audio I'm not sure this is related to my problem as in my case the audio is integrated to the motherboard.

EDIT: new Pulse Audio version 13.99.2: exact identical same problem, just a bit worse: now every single reboot you need to run the systemctl restart command. Now it never ever has a chance to give correct output device after a reboot!

Yuri6037 commented 3 years ago

Per https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1036, it seam that our problem is related to pipewire: if it solves the problem by manually restarting pulseaudio service and that randomly a reboot might fix itself could mean that pipewire boots at the same time and causes conflicts.

Maybe System76 can make one service start later?

Yuri6037 commented 3 years ago

Update from 12/07/2020: Now everything is broken: systemctl --user restart pulseaudio no longer has an effect. Sound is now completely unusable on my hardware. Unpluging Audio-jack and re-plugging has worked this time... It's highly unstable.

However strangely on a crappy laptop audio is much more stable: no more random bluetooth audio disconnection and when I start a connection with my bluetooth heatset I no longer have to hit quickly more than 100 times the same switch...

Hxs2fJKjYZ commented 3 years ago

I'm also having sound issues on one of my computers. Sometimes the computer will boot up and log in and there's no sound at all, but a simple reboot fixes the issues, the problem of when the issues happen seem pretty random, I haven't had time to take note of all of the above and see what exactly happens on the system but I will do that as soon as possible. The problem also started happening after a flurry of updates to the system not long ago, before which everything with the sound was fine

Yuri6037 commented 3 years ago

I advanced on the problem. I think I understand what pulse audio is trying to do: it is trying to dynamically detect which jack port is connected on the back of the motherboard and based on the connected port it now supports difference between rear and front audio it never did that before.

The only problem with this detection is when the motherboard gets powered initially no device will respond to the connected ports as the the two are:

I think what's happening is pulse-audio crashes when trying to assign the default "Line Out" device with it's default configuration on startup due to the fact that the ports initially are not connected and the external amplifier is never powered on when the computer is powered on.

At least what's interesting now is pulse audio now understands the difference between front and rear audio on this motherboard which is nice as I never ever saw a linux distribution before this update to be able to understand what is rear and front audio.

Hxs2fJKjYZ commented 3 years ago

Is there any solution to this? Sometimes I have to restart my computer 4 or 5 times before I can get the audio working, which is not what one would want. I have speakers connected to the rear jack only, not S/PDIF, and this is a recurring problem, maybe 1 in 3 or 4 boot ups.

Yuri6037 commented 3 years ago

You can try systemctl restart --user pulseaudio

Hxs2fJKjYZ commented 3 years ago

You can try systemctl restart --user pulseaudio

Thank you, pulseaudio -k also does the trick. But it's not something the user should have to keep doing every other boot up just to get sound working, would greatly appreciate a fix. Also, Happy new year and all the best to everybody for 2021 ;-) update I've setup pulseaudio -k to run on startup, which happily deals with the issue now, it was becoming a problem to kill it manually every other log in.

jonoave commented 3 years ago

Hello, just to add I'm experiencing the same issue as well.

My USB headset worked great on pop_os 20.04. After upgrading to 20.10, it either:

  1. doesn't detect it
  2. detects it but only the output (seen in speaker dropdown)
  3. detects both, but only one works at a time (seen in both speaker and mic dropdown, switching headset on either disables the other)
  4. both works!

The outcome is random upon every attempt of replugging it in. I've tried all the steps like reinstall, kill, restart etc on system-76 help pages but none works. The only solution seems to be to restart my laptop completely. However, now i've to be wary when i unplugged it and whether it will work again when I replug it.

Hoping to see a solution soon.

WereDev commented 3 years ago

@jonoave That has been my exact experience too. Worked great on 20.04, and I get the same issues as you on 20.10. Though after a couple attempts to get it to detect correctly, sometimes it stops being detected at all which requires a reboot. :-/ Seems like the issue is with PulseAudio as it shows up in Alsa just fine. There appears to be an updated version of PA that fixes the issue, but as of yet, it hasn't been included in a patch. Hopefully someone from Pop can get it into a patch, or maybe comment here and let us know the status. Either way, the lack of feedback or even recognition of this issue by Pop is quite frustrating.

zenlinux121 commented 3 years ago

Hello,

I faced the same issue of losing audio randomly or when I unplug my headphones or headset I plug it again and I see a dummy device in the pulseaudio devices. After researching the issue I found that killing all pipewire processes solved my issue.

In your case another process might be creating the issue so use the following information:

https://wiki.gentoo.org/wiki/PulseAudio#Dummy_output

Stop or kill the processes using your sound devices and and see if now pulseaudio can access the sound device and works again. I didn't restart pulseaudio service with: systemd --user restart pulseaudio.service.

I hope this helps someone.

thank you.

jonoave commented 3 years ago

Hi @zenlinux121:

Thanks for your comment. Sorry I'm a little unclear. on the notes provided in that link. When I typed in fuser -v /dev/snd/

I got lots of permission denied and finally some device. Which process is the one causing the issue and how do i I kill it? Thanks!

...
Cannot stat file /proc/2520/fd/58: Permission denied
Cannot stat file /proc/2520/fd/60: Permission denied
                     USER        PID ACCESS COMMAND
/dev/snd/controlC0:  jh     2105 F.... pulseaudio
/dev/snd/controlC1:  jh     2114 F.... pipewire-media-
/dev/snd/controlC2:  jh     2105 F.... pulseaudio
/dev/snd/pcmC2D0p:   jh     2105 F...m pulseaudio
/dev/snd/timer:      jh     2105 f.... pulseaudio
WereDev commented 3 years ago

Looking at the Ubuntu 21.04 package list, it appears that PulseAudio 14.2 is in the bundle so hopefully this all gets fixed with the PopOS release next month. :crossed_fingers:

Anyone happen to test with Ubuntu 21.04 to see if the issue is indeed resolved there?

i-garrison commented 3 years ago

There is not much of a chance to run pipewire<0.3.15 and pulseaudio simultaneously, there always will be some kind of conflict over audio devices. https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/1905168

If updating pipewire is not an option, I'd siggest picking one of the two audio servers or at least disabling audio part of pipewire as a workaround.

cstrahan-blueshift commented 3 years ago

Having similar problems: my Focusrite Scarlett 2i4 disappeared from pavucontrol/pacmd list-sinks/pacmd list-cards after waking from sleep. I saw this in systemctl --user status pulseaudio:

Jun 30 12:32:52 pop-os pulseaudio[79590]: Failed to load module "module-alsa-card" (argument: "device_id="3" name="usb-Focusrite_Scarlett_2i4_USB-00" card_name="alsa_card.usb-Focusrite_Scarlett_2i4_USB-00" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes avoid_resampling=no card_properties="module-udev-detect.discovered=1""): initialization failed.

After running sudo fuser -v /dev/snd/*, I realized the pipewire-media-session process was interfering with PulseAudio. So I ran the following to let PulseAudio lay claim to all sound devices:

$ systemctl --user stop pipewire                                                                                                                                                                                                                                                                                                                                                                                                                        
$ systemctl --user stop pulseaudio                                                                                                                                                                                                                                                                                                                                                                                                                        
$ systemctl --user start pulseaudio                                                                                                                                                                                                                                                                                                                                                                                                                        
$ systemctl --user start pipewire

That did the trick.

I'm actually quite surprised to see that PipeWire is installed at all, considering PulseAudio is also installed. Is this documented in PopOS (or further upstream)? I'm curious what the rationale is.

I see the following two pipewire processes are running:

WereDev commented 3 years ago

Good find! I didn't realize pipewire was on PopOs either. Following your example above, I stopped Pipewire and Pulse, then only started Pulse again and my USB headset was found consistently. I then disabled pipewire on my system (and reboot) with the below commands and so far no issues with how Pulse is identifying my headset.

systemctl --user mask pipewire.service
systemctl --user mask pipewire.socket
WereDev commented 3 years ago

Just wanted to report back to say that this solution continues to work for me. My USB headset continues to show up and work consistently since disabling pipewire.

spaghetticodez commented 2 years ago

Having similar problems: my Focusrite Scarlett 2i4 disappeared from pavucontrol/pacmd list-sinks/pacmd list-cards after waking from sleep. I saw this in systemctl --user status pulseaudio:

Jun 30 12:32:52 pop-os pulseaudio[79590]: Failed to load module "module-alsa-card" (argument: "device_id="3" name="usb-Focusrite_Scarlett_2i4_USB-00" card_name="alsa_card.usb-Focusrite_Scarlett_2i4_USB-00" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes avoid_resampling=no card_properties="module-udev-detect.discovered=1""): initialization failed.

After running sudo fuser -v /dev/snd/*, I realized the pipewire-media-session process was interfering with PulseAudio. So I ran the following to let PulseAudio lay claim to all sound devices:

$ systemctl --user stop pipewire                                                                                                                                                                                                                                                                                                                                                                                                                        
$ systemctl --user stop pulseaudio                                                                                                                                                                                                                                                                                                                                                                                                                        
$ systemctl --user start pulseaudio                                                                                                                                                                                                                                                                                                                                                                                                                        
$ systemctl --user start pipewire

That did the trick.

I'm actually quite surprised to see that PipeWire is installed at all, considering PulseAudio is also installed. Is this documented in PopOS (or further upstream)? I'm curious what the rationale is.

I see the following two pipewire processes are running:

* `/usr/bin/pipewire`

* `/usr/bin/pipewire-media-session -d bluez5`

Same issue, this workaround helps atm - just killing pulseaudio does not work 100%.

EDIT: Masking pipewire service and socket does not fix this issue, still have to kill the process (sometimes more than once...) - i mean pulseaudio -k. EDIT2: This mostly happens after standby/suspend wake up... commenting power save idle settings on pulseaudio did not help.