Audio dropping for less than a second randomly

[smilinmonki666]

I seem to have issues where playing audio via Spotify or RhythmBox will just drop for less than a second. The music isn’t pausing (and the fact that it’s across two audio apps) which indicates it’s audio related.

I can watch videos on YouTube fine without any dropping of audio.

I’ve had journalctl --follow running in the background to see if I can spot anything but nothing. I’ve noticed that NetworkManager throw’s an info level log entry in there which is the following:

Mar 21 22:25:38 pacman NetworkManager[581]: <info>  [1679437538.0166] device (wlan0): set-hw-addr: set MAC address to 62:EB:2C:8B:97:AF (scanning)
Mar 21 22:25:38 pacman NetworkManager[581]: <info>  [1679437538.5977] device (wlan0): supplicant interface state: inactive -> interface_disabled
Mar 21 22:25:38 pacman NetworkManager[581]: <info>  [1679437538.5978] device (p2p-dev-wlan0): supplicant management interface state: inactive -> interface_disabled
Mar 21 22:25:38 pacman NetworkManager[581]: <info>  [1679437538.6748] device (wlan0): supplicant interface state: interface_disabled -> disconnected
Mar 21 22:25:38 pacman NetworkManager[581]: <info>  [1679437538.6748] device (p2p-dev-wlan0): supplicant management interface state: interface_disabled -> disconnected
Mar 21 22:25:38 pacman NetworkManager[581]: <info>  [1679437538.6800] device (wlan0): supplicant interface state: disconnected -> inactive
Mar 21 22:25:38 pacman NetworkManager[581]: <info>  [1679437538.6801] device (p2p-dev-wlan0): supplicant management interface state: disconnected -> inactive

Then after 1 or more close glitches it’s fine again for a couple of minutes.

What else can I do to debug the issue as it’s really annoying me and I’m only experiencing it on EndeavorOS, but I don’t want to change distro

[smilinmonki666]

I’ve noticed that when the drop out happens a single CPU will peak for the same time as the drop out…

[anon11595408]

Perhaps you can narrow down the issue by identifying which process(es) are taking up much cpu, running htop or glances while music is playing and the dropouts occur.

Oh, and welcome to this forum, @smilinmonki666.

[smilinmonki666]

Thanks @anon11595408, I’ve been doing that and not noticed anything. Only problem with htop is that it updates quickly so not sure I’ll be able to confirm… Will keep trying though.

And glad to be part of the forum!

[smilinmonki666]

Hey @anon11595408, I’ve used glances (really nice tool) and I’ve identified that wpa_supplicant seems to be a common process at the time of the audio drop. I’ve taken a look at https://wiki.archlinux.org/title/Wpa_supplicant and I don’t seem to have anything under /etc/wpa_supplicant…

[anon11595408]

So at least, now we know it is not related to any audio-configuration but related to your WiFi instead.

Can you connect to your router via a lan-cable, instead of using wifi?

If not, can you re-configure your router to use a different wifi-band (5khz instead of 2khz, or vice versa for example)?

[smilinmonki666]

This is wired …

I’ve checked if this is streaming music only, but it’s not. Using Rhythmbox with local music is still showing the same issue and when wpa_supplicant shows in glances

I’ve attached a screen shot of my networks:

[anon11595408]

But wpa_supplicant is only needed for WiFi connections. Can you switch off your Wifi on HW level? If so, and it still comes up, report back.

EDIT: To stop wpa_supplicant from running for good, the service needs to be masked. See:

The sudo systemctl disable wpa_supplicant + sudo systemctl stop wpa_supplicant will ONLY temporarily disable wpa_supplicant service until the network manager restarts and/or the system reboots.

So, to correctly and/or completely disable the wpa_supplicant service from running again in the future even after the network manager restarts and/or the system reboots is to mask the service, i.e.

systemctl mask wpa_supplicant.service

etc., as pointed out in this article. This will create a symbolic file

/etc/systemd/system/wpa_supplicant.service → /dev/null

Source.

[smilinmonki666]

@anon11595408

sudo systemctl stop wpa_supplicant

I’ve tried the first two commands to temporarily disable the service, which as you said won’t persist. I’ve masked it and I’m testing after a reboot…

So far I’ve not managed to replicate the issue…

Next steps, if this happens would be to do upgrades… I’ve dragged a bit behind, so once that’s done at some point this week I will need to revert the mask and see if updates have fixed it, if not what would you want from me to help diagnose the issue further?

[anon11595408]

One thing at a time, please…
An update of the whole system is highly recommended, asap! - To prevent any future mis-haps, it might be recommendable to additionally install the lts-kernel:

sudo pacman -Syu linux-lts linux-lts-headers

Good luck!

[smilinmonki666]

So, your solution has fixed the issue… not. one. single. dropout! So, thank you very much!

I will certainly be updating my install, been playing around with it and setting up some stuff when I get chance. Normally keep my OS very much up-to-date - promise