I’m having the same issue. Restarting pulseaudio service is a temporary fix.
Audio stops working after a few minutes. Can’t seem to find anything specific that triggers it. Seems just doing anything for a couple minutes is enough.
Started happening after I installed the large set of updates yesterday.
Output of the systemctl status command is identical (except for PIDs and cpu time) when audio is not working, vs after restarting service when audio is working.
● pulseaudio.socket - Sound System Loaded: loaded (/usr/lib/systemd/user/pulseaudio.socket; enabled; preset: enabled) Active: active (running) since Wed 2022-12-07 11:10:56 MST; 1h 13min ago Until: Wed 2022-12-07 11:10:56 MST; 1h 13min ago Triggers: ● pulseaudio.service Listen: /run/user/1000/pulse/native (Stream) CGroup: /firstname.lastname@example.org/app.slice/pulseaudio.socket Dec 07 11:10:56 schwifty systemd: Listening on Sound System. ● pulseaudio.service - Sound Service Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; disabled; preset: enabled) Active: active (running) since Wed 2022-12-07 12:08:38 MST; 15min ago TriggeredBy: ● pulseaudio.socket Main PID: 6462 (pulseaudio) Tasks: 11 (limit: 9264) Memory: 9.4M CPU: 8.934s CGroup: /email@example.com/session.slice/pulseaudio.service ├─6462 /usr/bin/pulseaudio --daemonize=no --log-target=journal └─6478 /usr/lib/pulse/gsettings-helper Dec 07 12:08:38 schwifty systemd: pulseaudio.service: Consumed 17.767s CPU time. Dec 07 12:08:38 schwifty systemd: Starting Sound Service... Dec 07 12:08:38 schwifty pulseaudio: Path Capture is not a volume or mute control Dec 07 12:08:38 schwifty pulseaudio: stat('/etc/pulse/default.pa.d'): No such file or directory Dec 07 12:08:38 schwifty systemd: Started Sound Service. Dec 07 12:08:38 schwifty pulseaudio: Could not find org.bluez.BatteryProviderManager1.RegisterBatteryProvider(), is bluetoothd started with experimental features enabled (-E flag)?
Anyone able to say for sure which package is causing the problem? pulseaudio probably?
I’d like to check if the issue is reported in the appropriate place, so I can follow it. I don’t see a matching pulseaudio issue on bugs@archlinux at the moment.
Though it’s probably not pulseaudio since a gnome user in a separate thread switched to pipewire and had same issue…