Audio devices switching "randomly" (and at the worst times)

samteezy

I've got an issue that I thought was just a Zoom one, but it appears not to be so, and I need help troubleshooting it.

I have a Jabra Evolve 40 USB headset that I use for calls. Occasionally, when I'm on Zoom (via the flatpak) or Google Meet in Chrome, my audio devices will switch mid-call. It's as though the headset disconnects and comes back. Sometimes it won't switch back to the headset, it'll default, say, to my USB webcam, and I'll need to switch it back to the headset manually.

I have noticed that in Google Meet, it will not switch back, and even if I select the Jabra in the Google Meet settings the audio still runs through my webcam. What I did just find is that if I open the sidebar (Raven?) and toggle which audio devices Solus is using, the audio re-routes properly.

I never had this issue on my Windows laptop, and I'd like to figure out why this is happening and stop it since I work on my Solus desktop. The thing is, I can't reproduce it on demand. I can go for days without issues, and then sometimes have it happen once or twice a day for several days back-to-back.

Is there a way I can look at some sort of log and see what is happening?

clasclin

Have you tried to connect to every usb port? sometimes it's a usb issue.

Now answering your question

$ journalctl | grep pulseaudio
Doesn't seems to be verbose by default, but you can stop the sound server and then start it in verbose mode, that way you can see what's going on. But there is a catch, by default if stop the sound server it will autostart.

In order to avoid the sound server autostart when you stop it, you can edit a config file
Copy the file under your home directory
$ cp --verbose --interactive /usr/share/pulseaudio/client.conf ~/.config/pulse/
Open the file you just copy and change the autorestart feature
$ echo "autospawn = no" >> ~/.config/pulse/client.conf
Now you can stop the server
$ pulseaudio --kill
Start the server with the verbose option
$ pulseaudio -vvv

You probably want to check the documentation too, it's a lot

samteezy

Weird, because I have a response over email from @clasclin in my email inbox but I don't see it here in the thread...

That said, based reading the content of that post in my email, I ran $ journalctl | grep pulse audio and I got the following, timestamped perfectly to line up with the last issue I had prior to making the original post:

Jul 23 09:57:12 tributo pulseaudio[1849]: [alsa-sink-USB Audio] alsa-util.c: Got POLLNVAL from ALSA
Jul 23 09:57:12 tributo pulseaudio[1849]: [alsa-source-USB Audio] alsa-util.c: Got POLLNVAL from ALSA
Jul 23 09:57:12 tributo pulseaudio[1849]: [alsa-source-USB Audio] alsa-util.c: Could not recover from POLLERR|POLLNVAL|POLLHUP with snd_pcm_prepare(): No such device
Jul 23 09:57:12 tributo pulseaudio[1849]: [alsa-sink-USB Audio] alsa-util.c: Could not recover from POLLERR|POLLNVAL|POLLHUP with snd_pcm_prepare(): No such device

Going to research it further. In the meantime, I have tried moving the headset from the USB port in the front of my tower to a USB hub I have plugged into the back of the motherboard.

JoshStrobl

samteezy Weird, because I have a response over email from @clasclin in my email inbox but I don't see it here in the thread...

Akismet flagged it as spam for whatever reason. I had to approve it.