Search Criteria
Package Details: pulse-autoconf 1.10.2-2
Package Actions
Git Clone URL: | https://aur.archlinux.org/pulse-autoconf.git (read-only, click to copy) |
---|---|
Package Base: | pulse-autoconf |
Description: | PulseAudio server dynamic configuration daemon |
Upstream URL: | https://www.eomanis.dedyn.io/permshare/pulse-autoconf/ |
Keywords: | echo-cancellation mix pulseaudio streaming video-conference voice-chat |
Licenses: | GPL3 |
Submitter: | eomanis |
Maintainer: | eomanis |
Last Packager: | eomanis |
Votes: | 2 |
Popularity: | 0.000000 |
First Submitted: | 2020-08-07 14:13 (UTC) |
Last Updated: | 2024-09-25 21:16 (UTC) |
Dependencies (8)
- bash (bash-devel-static-gitAUR, bash-devel-gitAUR, busybox-coreutilsAUR, bash-gitAUR)
- bc (bc-ghAUR)
- coreutils (coreutils-gitAUR, busybox-coreutilsAUR, coreutils-hybrid-gitAUR, coreutils-uutilsAUR, coreutils-hybridAUR, coreutils-selinuxAUR)
- findutils (findutils-gitAUR, busybox-coreutilsAUR, findutils-selinuxAUR)
- grep (grep-gitAUR, busybox-coreutilsAUR, grep-compatAUR)
- libpulse (pulseaudio-dummyAUR, libpulse-gitAUR)
- sed (busybox-coreutilsAUR, sed-gitAUR)
- util-linux (busybox-coreutilsAUR, util-linux-selinuxAUR, util-linux-aesAUR)
Latest Comments
1 2 Next › Last »
hgabreu commented on 2024-01-19 16:24 (UTC)
Thank you, I'll give it a try.
eomanis commented on 2024-01-19 01:14 (UTC)
@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
andEchoCancellationWithSourcesMix
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 theEchoCancellationWithSourcesMix
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:
hgabreu commented on 2024-01-16 16:13 (UTC) (edited on 2024-01-16 16:13 (UTC) by hgabreu)
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:
hedgepigdaniel commented on 2023-08-24 02:46 (UTC)
Thanks for the fix, it works now without any overrides!
eomanis commented on 2023-08-14 09:59 (UTC) (edited on 2023-08-14 10:31 (UTC) by eomanis)
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:
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:Maybe it will work if you put that into your systemd drop-in file.
hedgepigdaniel commented on 2023-08-14 00:40 (UTC)
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):
eomanis commented on 2023-08-13 19:51 (UTC) (edited on 2023-08-13 21:16 (UTC) by eomanis)
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,
should instead be
I.e. it should whitelist access to the PulseAudio daemon's UNIX socket.
But why did that ever work then?
eomanis commented on 2023-08-13 19:37 (UTC) (edited on 2023-08-13 19:44 (UTC) by eomanis)
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 wrotepulse-autoconf.service
. Maybe thepactl
call from within thepulse-autoconf.service
sees it, but is not allowed to read it, and crashes.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 ownpulseaudio.service
where it belongs. And as you have found outpulse-autoconf.service
is pretty well locked down so thatpulse-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:systemd
is told to startpulse-autoconf.service
(in the systemd --user context)systemd
notices theRequires=
andAfter=pulseaudio.socket
systemd
"starts"pulseaudio.socket
, which creates a systemd-managed UNIX socket file at/run/user/1000/pulse/native
systemd
runs the/usr/bin/pulse-autoconf
executable/usr/bin/pulse-autoconf
callspactl
to do its thingspactl
attempts to connect to the PulseAudio daemon through the (systemd-managed) UNIX socket filesystemd
notices the connection attempt, "pauses"pactl
for a short time, and startspulseaudio.service
, which runs/usr/bin/pulseaudio
systemd
"hands over" the UNIX socket file to the/usr/bin/pulseaudio
processpactl
resumes operation and "talks" to/usr/bin/pulseaudio
through the UNIX socket fileWhen 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, usingpactl
.On your machine it looks like something goes wrong at step 6 or 7. When your
pactl
is called for the first time from withinpulse-autoconf.service
, it (possibly) does not find the UNIX socket file. Thereforepactl
thinks "Huh, the PulseAudio daemon is not running, I will start one myself", but this did not work out becausepulse-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.hedgepigdaniel commented on 2023-08-10 04:09 (UTC)
Good idea, I've done the override configuration file and that works. It looks like this:
I had to also disable
ReadWritePaths
, otherwise I think that turns onProtectHome
or something similar aswell.I don't understand what you mean about the pulse daemon? I do have the
systemd --user
unitspulse-autoconf.service
pulseaudio.socket
andpulseaudio.service
running and enabled.You seem to be implying that the fact that the
Requires
orAfter
configuration points topulseaudio.service
means that thepulse-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 theProtectHome=yes
is not affected byRequires
/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.eomanis commented on 2023-08-08 12:34 (UTC)
@hedgepigdaniel
It seems like the pulseaudio/pulse daemon is being started within the reduced-permission
systemd --user
service context ofpulse-autoconf.service
. This should not happen; the pulse daemon should run within its ownpulseaudio.service
systemd --user
service context, and to ensure this thepulse-autoconf.service
file contains these dependencies: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
:1 2 Next › Last »