Incidentally AlienBob has a decent tutorial on "shoving pulse to the curb" by substituting JACK here >>> https://alien.slackbook.org/blog/con...-use-as-a-daw/ and it should be noted that there is a LiveSlak DAW version if you prefer trying it first and seeing it's innards up close and personal.

3 members found this post helpful.

Nice!

BUT, I have some little bad news for you...

PulseAudio is (at least somewhat) aware of elogind (and ConsoleKit2 also) and it tries to auto-quit itself on user logout.

However, from my own experience of playing with Wayland/Plasma5, the Pipewire is a "user target" service, expected to be run by systemd.

And you know what is the irony? An "user target" service for systemd is completely unaware of the noble art of user authentication from systemd or whatever. Essentially, it is just a program which should be killed by systemd at user logout.

HOWEVER, our elogind has no such features, all it can do it to kill ALL user processes at user logout - which also will kill screen or tmux, making some people unhappy.

So, I suggest you to tune your logout script to kill the PipeWire processes.

1 members found this post helpful.

Well LuckyCyborg isn't that only true if you "startx" or "startfluxbox" etc. ? If you use SDDM as root, you can drop to any Runlevel 3 login with Ctrl-Alt-F(number) key. I just wish it was still offered an option to kill X in the process like KDM and early SDDM did. Commands even by a separate root login like "killall sddm" do nothing now. It pisses me off if I employ any part of X and decide to do something out of X, I have to reboot entirely just like freaking Windows FFS.

1 members found this post helpful.

init 3

3 members found this post helpful.

I was one of the pulse haters, and when I installed current, I didn't bother to turn it off. And...it really doesn't get in my way much. When jack's running, it isn't. (And I shouldn't be surfing youtube videos of urban explorers while writing music, anyway, but if I wanted to, Alien Bob's got a package that acts as a shim between the two.) I was leery of pulse for a good, long time, and it's bad for the kinds of music things I do. But when I'm not working on supercollider, pulse isn't noticeable.

Now watch, big issue will happen with an update, and I'll eat my words.

Instead of
, you have to use
if you want to kill the main SDDM process. "sddm" is just a wrapper script that will eventually execute the real SDDM process. If you run "killall sddm" while plasma is running, you will only kill the sddm wrapper script, not the main SDDM process itself, thus leaving SDDM and KDE plasma still running. I have already made a request last month (details in: https://www.linuxquestions.org/quest...ml#post6182882) suggesting to prepend "exec" to the "/usr/bin/sddm.bin" invocation in the /usr/bin/sddm wrapper script to avoid this kind of behaviour, but so far it's not applied yet. It's probably a low priority for Mr. Volkerding since you can still avoid it by never running "killall sddm" but instead just run "init 3" from the console (just like Mr. Hameleers suggested).

1 members found this post helpful.

KDE pretty-much uses pulseaudio. Since it is built on alsa, alsamixer and its friends work as well. Whenever I need to run jack for low-latency:

Then I can use the patchbay in QjackCtl to connect things up. When finished, ps ax | grep jack to kill the jack process and pulseaudio is restored so I can return to vlc playing the Bach streams at http://38.96.148.28:8342/ or http://audio.wgbh.org/Bach-8108-aac

1 members found this post helpful.

You can also keep the autostarting user specific with the ~/.config/autostart directory, which lets you leave the /etc/xdg/autostart directory as is.

In my case I copied the pulseaudio.desktop file from /etc/xdg/autostart/ to my ~/.config/autostart and then edited the desktop entry to include "NotShowIn=KDE", which prevents it from starting in KDE for my user only. You could alternatively opt for "Hidden=True" to disable the autostarting entirely. Note that the ~/.config/autostart entries takes precedence over the /etc/xdg/autostart directory for a .desktop entry with the same name.

Then I added pipewire.desktop and pipewire-pulse.desktop entries, also in the ~/.config/autostart directory. These I set to "OnlyShowIn=KDE". This results in pipewire only launching for my user, for a Plasma 5 session (x or wayland), while still launching pulseaudio in the other desktop environments.

I did notice that pipewire doesnt end cleanly as LuckyCyborg has pointed out. Since I'm running pipewire in plasma only I added a "plasma_shutdown.sh" script in ~/.config/plasma-workspace/shutdown/ with the following:
So far everything seems to be working and stopping when needed, and I'm getting sound through pipewire in a plasma session. Now to figure out the JACK integration and see if the realtime performance is any good out of pipewire.

2 members found this post helpful.

Keep the posts on pipewire in Plasma5 coming!

1 members found this post helpful.

(OT) Thanks for the Bach streams!

I run everything through JACK and Pulse is merely a conduit. Using QJackCtl to start and configure all of it.
Needs a few additional packages, see https://alien.slackbook.org/blog/con...-use-as-a-daw/

You probably do not want to kill all pipewire daemon instances.

Because for every user login session may is started an pipewire instance. IF somehow you are able to kill an other user pipewire daemon, his/her Wayland/Plasma5 desktop will crash totally. This will be certainly not so fun in a multi-seat setup (which is supported by elogind) or while running several desktops in parallel.

So, maybe this is a better solution:
And probably you will want this particular order, because the master program is the pipewire daemon.

3 members found this post helpful.

Any non-root user shouldn't be able to kill other users' processes, but that is a good change anyway (in case root runs Plasma5, even if it isn't recommended).

That's a reasonable precaution. I had only been testing pipewire for my user account and wasn't thinking about the multiuser situation. With my setup, pipewire starts and stops with plasma, hence killing both at the end. Not claiming best practice here, just trying to get started on experimenting.

I take it you run pipewire system wide from /etc/autostart/pipewire.desktop and then launch pipewire-pulse during your wayland or X session from your user?

It's hard to know the best practice for running pipewire when the documented method is with a user targeted systemd service. Not sure how to mimic that functionality without systemd so I guess we try to come up with the best alternative. The software still works, it's just too bad the daemon can't manage itself a little nicer.

2 members found this post helpful.

After asking my Fedora friends about what systemd do with the "user target" daemons, I started to believe that the best way to simulate this systemd feature is to use a daemon supervisor, an idea which I borrowed from a post made by LuckyCyborg.

A bit of background: a daemon supervisor is a daemon which is able to run in background a given program and ideally to start only a single instance which is watched for its properly run, eventually starting again the program if it crashes.

There are daemon supervisors like daemontools or other simpler implementations like is daemonize which already have a SlackBuild.

However, to simulate an "user target" daemon supervisor doing the the job in similar ways like systemd, we need a supervisor which is capable also to talk with elogind, for watching the user logout, and if this happens to quit its instance and the inner running program.

The bad news are that there is not such thing yet, even we should expect more and more "user target" daemons to appear in the wild.

Looking for the available daemon supervisor in the wild, I started to consider that the best candidate is this daemon, because it has even the ability to respawn the inner program, to run it in a single instance with pid files and even to stop/start/restart it.

But, it should be further patched for elogind integration and I am not a C/C++ programmer and apparently in this community are no C/C++ programmers, that's why I tried opening a feature request there: https://github.com/raforg/daemon/issues/1

I believe that would be nice if others will jump in this feature request to support it too and will be even nicer if there will jump bigger names like Mr. Hameleers or Mr. Workman.

Facts are that we need a daemon supervisor with elogind support not only for PipeWire, but certainly for other possible "user target" daemons which in future we will discover that we will want to run.

2 members found this post helpful.