Tanu Kaskinen wrote on 13/10/2021 20:25:
On Wed, 2021-10-13 at 14:51 +0000, Joel wrote:
Tanu -
Thank you. I made the changes you suggested (removed
pulseaudio.socket from two locations where I found the file:
/etc/systemd/system/and /etc/systemd/system/sockets.targets.wants.
In the file pulseaudio.service, I commented out the lines
"Requires=pulseaudio.socket"; "ConditionUser=!root" and
"Also=pulseaudio.socket". Please note that there also two
occurrences of this file: /etc/systemd/system/and
/etc/systemd/system/multi-user.targets.wants. Perhaps the second
occurrences are system-generated.
I then had sound from the web browser! VLC was still providing sound
as before (but I gather not using pulsesaudio). After logging out
then logging back in (not rebooting), there was no web browser sound
and a new error: Failed to load module "module-x11-publish". This
also occurred after rebooting and booting from a cold start. After
the reboot, a further error arose: Error opening PCM device front:0:
Device or resource busy. Also, the /var/run/.pulse cookie does
exist. The systemctl status reports in full are at
https://susepaste.org/99540079 . I'm unable to determine what I did
to cause these errors.
The module-x11-publish error is probably caused by
/etc/xdg/autostart/pulseaudio.desktop, which is loaded on login,
causing /usr/bin/start-pulseaudio-x11 to be run. You could try removing
the pulseaudio.desktop file (take a backup if you want). You shouldn't
lose any essential functionality by doing that (and since PulseAudio
was unable to connect to X11, whatever PulseAudio wanted to do didn't
succeed anyway).
If you see "Device or resource busy", something else is using the ALSA
device. You can check with "lsof /dev/snd/*" what programs are using
the ALSA devices.
Forgive my ignorance since it's been *years* since I did any PA hacking
(just a drive by message on the list as I clicked on the folder in my
email client!) but do you really want your system-wide PA instance
running as root (that's what the systemd unit files suggests!)
Wouldn't you want a User=pulse in there in the system unit (and make
sure the user pulse can access the audio devices via suitable ACLs/group
ownerships)
It would be fine to have a system-wide pulseaudio.socket here that
started up the system-wide pulseaudio.service?
Or have things changed so much that the system-wide pulseaudio instance
no longer runs as the pulse user?
Col
