@ LuckyCyborg

In my testing with ~/.xinitrc, pipewire exits by itself at the end of a startx session. Pipewire also complains and exits if you try to start a second instance of it on d-bus. Based on that, I'm not sure how necessary it is to keep track of its pid and such. I was working on a script that detected user login and logout from elogind, although I scrapped the idea since it doesn't distinguish graphical login from tty. I'll share that code, maybe you can use some part of it to help in your cause to get user targeted daemons working. Basically is a script that is meant to be run like a daemon in the background, and runs scripts in a users login and logout directories when elogind reports them logging in or out (see comments in script). User's scripts are only triggered on first login for a user, and last logout. Also note I didnt intend on "releasing" this so it may not be great coding. Just a project for trying to listen to elogind: https://pastebin.com/aVWgskSd

On the topic of JACK:

Having all audio platforms "just work" is nice, although there is a clearly some glitches still. I have noticed that firefox started acting up and "lagging" every few seconds while testing the fully pipewire setup. Chromium seems to be working fine however. It's also nice that pipewire exposes all sound connections in the graph. Makes it easy to route audio from a browser to jack effects and back: just start the programs and connect the audio in the graph. Obligatory screenshot of what I mean: https://i.imgur.com/7mVi5mO.png

2 members found this post helpful.

Something else to report about pipewire, if I can continue putting info here: It tries to use rtkit to set realtime privileges for audio applications. Particularly this line in /etc/pipewire/pipewire.conf, which enables pipewires rtkit module:
That module tries to reach RealtimeKit on the system d-bus, which is a daemon that runs on the system bus and gives out realtime privilege to programs.

Slackware does not have rtkit installed so launching programs with pipewire in charge of audio shows it complaining and throw some errors about not being able to obtain a realtime thread. I tried commenting out that line and setting up realtime via booting with 'threadirqs' and setting rtprio and unlimited memory for the audio group with a /etc/security/limits.d/rt_audio.conf file, as outlined in alienBob's blog post on DAW configurations. However, pipewire's rtkit module still complains about trying to obtain realtime privilege, so the module is still active even with that config option commented out. Not sure what to make of that.

I'm also testing pipewire out with rtkit to see how that runs. There's no slackbuilds for rtkit out there so I built it from source here: https://github.com/heftig/rtkit. It built fine when I hacked together a package for it, the systemd dependency is optional. It also requires a rtkit user/group to run. I set that up the same as fedora's rpm install script from their rtkit package.
So far it seems to be working and RealtimeKit is running on the system d-bus. I can now turn the buffer size down in ardour to lower levels and record without xruns. Prior to getting rtkit running I was getting many xruns while recording at the same settings.

7 members found this post helpful.

THis looks promising 0XBF Bob. If you get this to run, I think I need to add rtkit to my package collection for the DAW and look at some proper out-of-the-box configuration. I'd also consider replacing pulseaudio with the pipewire drop-ins if that turns out to be stable.

6 members found this post helpful.

I have been messing around with attempting to get pipewire to start and stop with a wayland session.

While starting and stopping of pipewire in my ~/.xinitrc seems to work fine with X11 sessions (as I talked about earlier in this thread), pipewire just seems to want to stick around after a plasma-wayland session.

I'm wondering if it has to do with the use of "dbus-launch --exit-with-session" in /usr/bin/startkwayland? From my understanding of the manual, it sounds like dbus-launch spawns a babysitter process to talk to the X server and then kill the dbus programs when the X server dies. However, on wayland there wouldn't be an X server running so dbus-launch has different behavior and doesn't run this babysitter process. Maybe someone with more experience will correct me on that.

Anyway, I have been running my plasma-wayland sessions a little differently to get pipewire to start and stop with the session. I have this first script in my home directory "bobskwayland":
The first change there is to just use "dbus-run-session". I don't think it matters much vs dbus-launch since the X babysitter process shouldn't run in either case, but using that command will set its environment with the DBUS_SESSION_BUS_ADDRESS variable, verses using the "eval" with the "dbus-launch --sh-syntax" method. The other key thing its that I call a second script, which also inherits the DBUS_SESSION_BUS_ADDRESS environment variable. The "if" check is just to stop this script from being re-run after the session is started.

Then in that ".wayland-plasma" script I just have this:
That script starts pipewire, redirecting stderr to /dev/null, and backgrounds it. That pipewire session will be on the right dbus, thanks to the DBUS_SESSION_BUS_ADDRESS variable. Then it runs "startplasma-wayland", which will also know the proper dbus address. Once the plasma-wayland session ends (the user logs out), the pkill line is reached and pipewire is taken down with it.

I redirected pipewires stderr to /dev/null because pipewire spews lots of messages to the console otherwise. Still works without it but there's a few seconds of console spew after exiting the wayland-session, before pipewire exits.

After all that I have been enjoying wayland sessions for the last few days. Operation seems pretty stable (wayland and pipewire), and the memory usage seems a little lower than X11. I'm still using pipewire to cover pulseaudio and jacks role and overall I haven't had too many problems after getting rtkit working.

Also wanted to reply to Eric:
I think it would be a nice step forward to run a DAW through pipewire/rtkit, if just for the ease of setting up the audio backend. I have played around in my wayland session with ardour, zyn-fusion, and my MIDI keyboard, and overall the results have been very good. No random crashes so far with the latest pipewire, and the audio integration is nice.

To explain what I mean: I have the keyboard on a MIDI cable to a Scarlett audio interface, that interface is on USB to my laptop, and my headphones are on my laptop's headphone jack, which is a separate sound card. All that is available to pipewire without any extra tweaking (after pulse/jack backends are in place). In the past that needed running a2j to get the midi in, and bridging pulse to jack for the audio to get to that output. Now I just click the right input and output in ardour and things just work, didn't even need to open qjackctl.

My only worry is if it's still unstable and crashes that would be a deal breaker. Especially if that causes the loss of recorded audio before getting a save in there. I haven't seen random crashes in my latest testing, but then I haven't been doing too much in an audio session with it yet.

Not that we allow ourselves to be influenced by what other distros do, but Fedora34 proposes to have pipewire replace pulseaudio.

chris

Thanks, chris.willing. That looks rather promising to end the divide between Desktop and Pro Audio users while accommodating both and still providing use case options.

Maybe ZhaoLin1457's idea to use a "daemon supervisor" and to launch pipewire via XDG autostart is the one to follow...

Looks like the daemon's author is interested on that feature request and they started discussing the details.

https://github.com/raforg/daemon/issues/1

No offense to anyone, but I believe would be very nice if a native or a really good English speaker with interests on Pipewire As Audio Server would jump into discussion. From my own experiences, I know that sometimes the cultural differences may lead to misunderstandings.

As plus, probably more are the discussion participants, more will be shown the possible interest for implementing this feature.

From what I read and on my understanding, the idea is to get a generic way to execute "user target" services, using that "daemon" as a program supervisor which runs/stops pipewire or other similar programs with respawing on crashes and auto-quitting when user logouts.

In the end, looks like all will be reduced at
And that "daemon" will supervise and control the pipewire instance, including keeping it alive and killing it when user logouts.

If they manage to do that, this design probably would be useful for any "user target" services which we will want to run in future.

2 members found this post helpful.

+1 integrating daemon in slackware

I'm sure a daemon supervisor could be set up to accomplish babysitting pipewire, and perhaps this dev will be willing to work on that. I'm not sure how likely it is to be included in slackware but even on SBo would be helpful. My education and experience in C programming is minimal so I don't think I could jump in there with ideas myself. I'll gladly test and troubleshoot things if it helps. Also, I read his case on the github page and I followed it well enough as a native English speaker. Grammatically there are some minor issues but I think he wrote it out clear enough to follow for someone who understands the technical side of things.

I also registered an account on gitlab and posted this issue to the pipewire devs. Hope I was clear enough with that

https://gitlab.freedesktop.org/pipew...e/-/issues/500

Hopefully we will see some response from them.

2 members found this post helpful.

Well, if you contacted the Pipewire team, you may ask for a feature (eventually guarded by a command switch to not interfere with systemd's business - they are payed by RedHat, after all) where the PipeWire daemon(s) to watch via DBUS for their user logout and to commit suicide when this event happens, kinda like PulseAudio do.

If they add this feature of daemon(s) quitting on user logout, all we have is to start the PipeWire daemon(s) via XDG autostart, like PulseAudio.

For the other "user target" services we will want to run in future - and certainly there would be others, probably the daemon supervisor idea is great.

BTW, how about to propose the inclusion of that "daemon" in Slackware?

After all, it is something like a mini-daemontools and probably it would be greatly useful for the Slackware services even without the prospect of being elogind aware.

As plus, its author would be probably more inclined to hear us, knowing that his creation is included in one of most titrated Linux distributions in the World. Even today we aren't that so big.

@0XBF

RE @wtaymans's reponse
Because it is a "user target" daemon and systemd should take care about killing the PipeWire daemon(s) at the proper time.

Honestly, I believe that's better to explain to this gentleman about that non-systemd distros has no ways to stop those "user target" daemons.

Yet, at least until ZhaoLin1457 succeeds and that "daemon" is capable of full babysitting of those systemd services.

So, the watching over DBUS the user logout is probably the single way.

@0XBF

RE @wtaymans's reponse
At least from my own experience, the PipeWire daemon(s) are quite happy to be launched via XDG autostart desktop files, just like the PulseAudio, BUT at least apparently the PA also does two things:
1. it does some kind of instance checking, and only a single daemon instance is started for a given user
2. it watches the user login sessions via DBUS and CK2 or elogind, and quits itself on user logout - I have just received another confirmation from a friend who was kind to take a look into its code.

So? Most certainly they can do also this.

PS. Please bear in mind that you talk to a RedHat guy, so as I commented, those customizations certainly is better to be hidden behind a command switch - systemd certainly will not be so happy if one of its services commits suicide and maybe even will try to start it again.

Indeed I am trying to give a concise answer of what pulseaudio is doing differently to exit so I am currently trying to figure that out.

There is "module-console-kit" and "module-systemd-login" for pulseaudio. When I re-enabled pulse, I see that the console kit module is loaded. I also noticed that pulse is not exiting on logout since I can continue playing music after logout from init 3. However, it does exit after an idle period, I think due to "module-suspend-on-idle". Pulse also doesn't seem to rely on a user dbus session so that issue doesn't affect pulseaudio after logging out and back in. If the pulse server was running, the later login just reuses the existing pulse server.

I'll try to load the systemd module and see if that does anything differently with elogind now that we're using it. Hoping I can piece together a reply soon.

1 members found this post helpful.

Please bear in mind also that RIGHT NOW, our PulseAudio package is not built against elogind but ConsoleKit2.

In fact, you can look to what Gentoo do, if you want to build PA against elogind. Is matter of a switch and CFLAGS. I did it in the past, if you want, I will look if I still have that modified build. Eventually, I will "remake" the build.

I for one, as I use the Kill Mode on elogind for PipeWire, so also PulseAudio goes South.

LATER: I found some notes
That's with ol'good configure

I couldn't figure out how to build that elogind/systemd module or make it work but from what I understand it just autospawns pulseaudio at login and doesn't take it out at exit. The reason I say this is because I still have an older slackware64-current install on another machine that is pre PAM/elogind/etc, and still running consolekit on a ktown release happily. The "module-console-kit" module does nothing to kill pulseaudio at exit, only the 20 second "exit-idle-time" timer is killing pulse on that machine. The same is true with the latest edition of slackware64-current. I guess it never caused problems yet so nobody has questioned it.