On Tue, Jan 11 2022 at 01:37:22 PM, Greg Wooledge <g...@wooledge.org> wrote:
> On Tue, Jan 11, 2022 at 12:42:11PM -0500, Roy J. Tellason, Sr. wrote:
>> On Tuesday 11 January 2022 11:24:27 am Greg Wooledge wrote:
>> > But if I let it start itself automatically on demand, then it works
>> > straight out of the gate with no issues. So far, anyway!
>>
>> How does that "on demand" thing work?
>
> I have no idea, really. I can describe what it looks like, though.
>
> I've commented out everything having to do with pulseaudio from my
> .xsession file, so nothing that I do when I login or when I start X
> touches audio.
>
> When I open an application that uses audio, I get one of these guys:
>
> unicorn:~$ ps auxw | grep pulse
> greg 846 6.5 0.2 1682936 28676 ? S<sl Jan05 585:10
> /usr/bin/pulseaudio --daemonize=no --log-target=journal
>
> unicorn:~$ systemctl --user status pulseaudio
> ● pulseaudio.service - Sound Service
> Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; enabled;
> vendor >
> Active: active (running) since Wed 2022-01-05 08:48:08 EST; 6 days ago
> TriggeredBy: ● pulseaudio.socket
^^^^^^^^^^^^^^^^^
It uses the socket-activation support provided by systemd. The
pulseaudio.socket unit configures systemd to listen on
/run/user/<uid>/pulse/native for incoming pulseaudio client. When one
comes along, systemd will start the corresponding pulseaudio.service.
> Main PID: 846 (pulseaudio)
> Tasks: 3 (limit: 14199)
> Memory: 25.9M
> CPU: 9h 45min 13.290s
> CGroup:
> /user.slice/user-1000.slice/user@1000.service/app.slice/pulseaudio>
> └─846 /usr/bin/pulseaudio --daemonize=no --log-target=journal
>
> Jan 05 08:48:05 unicorn systemd[825]: Starting Sound Service...
> Jan 05 08:48:08 unicorn pulseaudio[846]: Failed to open cookie file
> '/home/greg>
> Jan 05 08:48:08 unicorn pulseaudio[846]: Failed to load authentication key
> '/ho>
> Jan 05 08:48:08 unicorn systemd[825]: Started Sound Service.
>
> It just chews up the CPU, doesn't it? I guess the Pulse guys can afford
> to be lazy about keeping the thing reined in, given how powerful current
> PCs are. Hell, even between those two commands, it used up 3 seconds of
> CPU, and I'm not even playing any audio right now!
