Thank you, I'll give it a try.

@hgabreu I have since migrated my audio setup to PipeWire, which incidentally got rid of some audio glitches, some GNOME Shell audio settings integration glitches, and which improved latency. Also, a "Main sink" is no longer required; in PipeWire the echo cancellation module can read the audio it should cancel directly from the default/fallback audio output. Very convenient.

The linked wiki section and the one below it cover functionality analogous to the EchoCancellation and EchoCancellationWithSourcesMix pulse-autoconf presets, respectively, and can be achieved without any user-space daemon running all the time. (The 2nd setup requires a manual once-after-pc-startup user interaction in Helvum which one could probably automate with some extra Wireplumber configuration, but I did not bother.)

Is that an option for you as well? I mean, sooner or later PulseAudio will start suffering from bit rot or desktop integration issues anyway, whereas PipeWire might very well be the go-to audio subsystem for years to come.

One more thing to consider: With pulse-autoconf I was reluctant to use the EchoCancellationWithSourcesMix all the time because it requires multiple loopbacks, which I suspect make the CPU work more.

In contrast, the analogous PipeWire setup does not require loopbacks, and because of that I have it enabled all the time with no ill effects on the CPU. Also, no loopbacks = no latency when playing into the sound effects sink, which I appreciate.

To get you started, I have these packages installed now:

gst-plugin-pipewire
helvum
lib32-libpipewire
lib32-pipewire
libpipewire
libwireplumber
pipewire
pipewire-alsa
pipewire-audio
pipewire-docs
pipewire-pulse
qemu-audio-pipewire
wireplumber

I've just updated pulseaudio from 16.1-7 to 17.0-1 The sink_main doesn't show up anymore, and I get the following on the logs:

Jan 16 09:58:36 . pulseaudio[1480]: No remapping configured, proceeding nonetheless!
Jan 16 09:58:36 . pulse-autoconf[14326]: Failure: No such entity
Jan 16 09:58:36 . pulseaudio[1480]: No such source.
Jan 16 09:58:36 . pulseaudio[1480]: Failed to load module "module-loopback" (argument: "latency_msec=60 max_latency_msec=100 adjust_time=6 source=src_ec sink=sink_mix"): initialization failed.
Jan 16 09:58:36 . pulse-autoconf[14328]: Failure: Module initialization failed
Jan 16 09:58:36 . pulse-autoconf[1247]:  WARN  A "pactl load-module" call failed with exit code 1. Further arguments: module-loopback latency_msec=60 max_latency_msec=100 adjust_time=6 source=src_ec sink=sink_mix
Jan 16 09:58:36 . pulseaudio[1480]: No such sink.
Jan 16 09:58:36 . pulseaudio[1480]: Failed to load module "module-loopback" (argument: "latency_msec=60 max_latency_msec=100 adjust_time=6 source=sink_fx.monitor sink=sink_main"): initialization failed.
Jan 16 09:58:36 . pulse-autoconf[14330]: Failure: Module initialization failed
Jan 16 09:58:36 . pulse-autoconf[1247]:  WARN  A "pactl load-module" call failed with exit code 1. Further arguments: module-loopback latency_msec=60 max_latency_msec=100 adjust_time=6 source=sink_fx.monitor sink=sink_main

Thanks for the fix, it works now without any overrides!

Yeah, it's weird that it worked - maybe systemd wasn't enforcing those rules properly until recently?

I think you are right about systemd not enforcing these rules on my system, which is why it works for me and not for you. Log excerpt from my system:

Aug 13 19:52:10 my-system (autoconf)[1046]: pulse-autoconf.service: Failed to set up user namespacing for unprivileged user, ignoring: Operation not permitted

This seems to be because I have unprivileged user namespaces disabled on my system.

You have found a bug in pulse-autoconf.service that makes it not work as intended when user namespaces are enabled, which is the default on Arch Linux. I shall fix that bug, but it will take a week or two because I am currently otherwise busy.

Thank you for notifying me even though I still do not have a proper bug tracker 👍

The fix to pulse-autoconf.service might look like this:

[Service]

# Provide access to the configuration files of pulse-autoconf
ReadOnlyPaths=/usr/lib/pulse-autoconf
ReadOnlyPaths=/etc/pulse-autoconf
ReadOnlyPaths=/run/pulse-autoconf
ReadOnlyPaths=%h/.config/pulse-autoconf

# Provide access to the configuration files of PulseAudio, because pactl might need to read them
ReadOnlyPaths=/usr/lib/pulse
ReadOnlyPaths=/etc/pulse
ReadOnlyPaths=/run/pulse
ReadOnlyPaths=%h/.config/pulse

# The directory where pulse-autoconf creates its instance lock file
ReadWritePaths=/run/user/%U/pulse-autoconf

# The path to the PulseAudio UNIX socket
ReadWritePaths=/run/user/%U/pulse/native

Maybe it will work if you put that into your systemd drop-in file.

Yeah, it's weird that it worked - maybe systemd wasn't enforcing those rules properly until recently?

Here's a configuration that seems to work (ReadWritePaths doesn't work with ProtectHome apparently):

$ cat /etc/systemd/user/pulse-autoconf.service.d/protect-home-no.conf
[Service]
ReadWritePaths=
ProtectHome=tmpfs
BindPaths=%t/pulse %E/pulse

Edit

No, scratch that, it is correct. pulse-autoconf creates its lock file there.

Uh, maybe I messed up in pulse-autoconf.service.

Pretty sure,

ReadWritePaths=/run/user/%U/pulse-autoconf

should instead be

ReadWritePaths=/run/user/%U/pulse

I.e. it should whitelist access to the PulseAudio daemon's UNIX socket.

But why did that ever work then?

Edit

You have a /home/dcal/.config/pulse/daemon.conf PulseAudio user-level configuration file. I do not think I thought about this when I wrote pulse-autoconf.service. Maybe the pactl call from within the pulse-autoconf.service sees it, but is not allowed to read it, and crashes.

You seem to be implying that the fact that the Requires or After configuration points to pulseaudio.service means that the pulse-autoconf service would therefore have access to the directories /run/user/<pid>/pulse, ~/.config/pulse, etc.

Not what I meant. Your log makes me suspect that your /usr/bin/pulseaudio process (the PulseAudio daemon) is trying to start "within" pulse-autoconf.service, instead of in its own pulseaudio.service where it belongs. And as you have found out pulse-autoconf.service is pretty well locked down so that pulse-autoconf may only do what it needs to do, to satisfy the principle of least privilege.

When pulse-autoconf.service is started, this is what should happen:

1. systemd is told to start pulse-autoconf.service (in the systemd --user context)
2. systemd notices the Requires= and After=pulseaudio.socket
3. systemd "starts" pulseaudio.socket, which creates a systemd-managed UNIX socket file at /run/user/1000/pulse/native
4. systemd runs the /usr/bin/pulse-autoconf executable
5. /usr/bin/pulse-autoconf calls pactl to do its things
6. pactl attempts to connect to the PulseAudio daemon through the (systemd-managed) UNIX socket file
7. systemd notices the connection attempt, "pauses" pactl for a short time, and starts pulseaudio.service, which runs /usr/bin/pulseaudio
8. systemd "hands over" the UNIX socket file to the /usr/bin/pulseaudio process
9. pactl resumes operation and "talks" to /usr/bin/pulseaudio through the UNIX socket file

When all that is done, /usr/bin/pulse-autoconf should be running "in" pulse-autoconf.service, and /usr/bin/pulseaudio should be running "in" pulseaudio.service. /usr/bin/pulse-autoconf should then "talk" to /usr/bin/pulseaudio through the UNIX socket file, using pactl.

On your machine it looks like something goes wrong at step 6 or 7. When your pactl is called for the first time from within pulse-autoconf.service, it (possibly) does not find the UNIX socket file. Therefore pactl thinks "Huh, the PulseAudio daemon is not running, I will start one myself", but this did not work out because pulse-autoconf.service is locked down in such a way that nobody in there may create a UNIX socket at that path. And this is where your error log comes from.

Good idea, I've done the override configuration file and that works. It looks like this:

[Service]
ProtectHome=no
ReadWritePaths=

I had to also disable ReadWritePaths, otherwise I think that turns on ProtectHome or something similar aswell.

I don't understand what you mean about the pulse daemon? I do have the systemd --user units pulse-autoconf.service pulseaudio.socket and pulseaudio.service running and enabled.

You seem to be implying that the fact that the Requires or After configuration points to pulseaudio.service means that the pulse-autoconf service would therefore have access to the directories /run/user/<pid>/pulse, ~/.config/pulse, etc. I can't find anything in the systemd docs to indicate that? It seems to me that the ProtectHome=yes is not affected by Requires/After, and is operating as intended, preventing pulse-autoconf from accessing those directories and therefore discovering the PID of the pulseaudio daemon and connecting to it.

@hedgepigdaniel

It seems like the pulseaudio/pulse daemon is being started within the reduced-permission systemd --user service context of pulse-autoconf.service. This should not happen; the pulse daemon should run within its own pulseaudio.service systemd --user service context, and to ensure this the pulse-autoconf.service file contains these dependencies:

[Unit]
Requires=pulseaudio.socket
After=pulseaudio.socket

I do not know why on your system these dependencies have no effect. You have a workaround that seems to function, but I cannot tell what else will break for the pulse daemon if it is being run within the pulse-autoconf.service context, so your mileage may vary until you find a proper fix.

Until then you can override ProtectHome without having to edit the package-supplied .service file with a systemd unit drop-in by placing this text file at /etc/systemd/user/pulse-autoconf.service.d/protect-home-no.conf:

[Service]
ProtectHome=no