Using Pipewire instead of Pulseaudio in Slackware 15
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Highlights
- Zoom, telegram and other apps should be able to play sound again.
- Implement a better way to force and lock JACK buffersize.
- Default sink and source names and properties are improved.
- The config loader can now load and merge fragments in conf.d directories for easier user configuration of config files.
- Many small bug fixes and improvements.
Highlights:
- Added bluetooth profile auto-switching support. Bluetooth headsets will now
automatically switch to the HSP/HFP profile when making a call and go back
to the A2DP profile after the call ends (#90)
- Added an option (enabled by default) to auto-switch to echo-cancel virtual
device nodes when the echo-cancel module is loaded in pipewire-pulse, if
there is no other configured default node
Howdy y'all! Quick PSA for folks hoping to use Alien Bob's pipewire-jack package: the version in his repo is older than the version of pipewire shipped in Slackware 15.0 (0.3.39 v. 0.3.44), so I needed to build it myself:
Code:
# As root:
mkdir pipewire-jack
cd pipewire-jack
# Download the SlackBuild...
wget http://www.slackware.com/~alien/slackbuilds/pipewire-jack/build/pipewire-jack.SlackBuild
wget http://www.slackware.com/~alien/slackbuilds/pipewire-jack/build/slack-desc
wget http://www.slackware.com/~alien/slackbuilds/pipewire-jack/build/slack-required
# ...and the source
wget https://mirrors.slackware.com/slackware/slackware64-15.0/source/l/pipewire/pipewire-0.3.44.tar.lz
# The SlackBuild needs the real JACK's development libraries present, so install jack2, too:
wget http://www.slackware.com/~alien/slackbuilds/jack2/pkg64/15.0/jack2-1.9.20-x86_64-1alien.txz
installpkg jack2-1.9.20-x86_64-1alien.txz
# Build it
export TAG=yellowapple # optional, but makes it obvious who built it
export VERSION=0.3.44 # required
./pipewire-jack.SlackBuild
upgradepkg /tmp/pipewire-jack-${VERSION}-x86_64-1${TAG}.txz
removepkg jack2 # To guarantee we're actually using PipeWire's JACK server
Before I did this, the version mismatch produced SIGSEGVs whenever I tried to run anything using JACK (tested against Ardour and QJackCtl); now everything works perfectly. One of those things that seems obvious now that I figured it out, but was driving me nuts all night before I spotted my mistake. Posting here in case anyone else runs into this in the hopes that it saves someone from the elevated blood pressure
Howdy y'all! Quick PSA for folks hoping to use Alien Bob's pipewire-jack package: the version in his repo is older than the version of pipewire shipped in Slackware 15.0 (0.3.39 v. 0.3.44), so I needed to build it myself:
...
Before I did this, the version mismatch produced SIGSEGVs whenever I tried to run anything using JACK (tested against Ardour and QJackCtl); now everything works perfectly. One of those things that seems obvious now that I figured it out, but was driving me nuts all night before I spotted my mistake. Posting here in case anyone else runs into this in the hopes that it saves someone from the elevated blood pressure
I first thought it was the same as http://www.slackware.com/~alien/slac...pipewire-jack/ but actually you disable direct Jack server support and only leave the Pipewire compatibility layer for Jack clients. So it is different.
I first thought it was the same as http://www.slackware.com/~alien/slac...pipewire-jack/ but actually you disable direct Jack server support and only leave the Pipewire compatibility layer for Jack clients. So it is different.
Yes, this means one package(jack) including daemon less, but still jack support.
For Jack clients pipewire looks like a jack-server, clients may be connected as usual with e.g. the QjacktCtl patchbay.
Jack apps need to be built with the libraries from this package.
Does this mean a package I installed which depends on Jack libraries will no longer work if I remove the jack package and install pipewire-native-jack instead?
That would be a no-go area for me.
I have no control over all the Jack-dependent applications I use. And Pipewire is still not on-par with Jack so I would like to be able to choose at runtime what I want to use, not compile-time.
Does this mean a package I installed which depends on Jack libraries will no longer work if I remove the jack package and install pipewire-native-jack instead?
I didn't try, but i guess it's very unlikely that the libraries are identical.
Quote:
And Pipewire is still not on-par with Jack so I would like to be able to choose at runtime what I want to use, not compile-time.
Then pipewire-native-jack is not for you. DAW users might have to stick to jack/pipewire-jack for while, but i hope pipewire evolves so it's jack-component when matured might end up in slackware 15.x.
Pipewire can be build to be able to choose at runtime which jack to use(pw-jack is for that), but it feels not handy to me and it is
unclear to me how jack-clients should be built then.
So atm pipewire-native-jack provides an easy way to have jack-support in slackware 15.0 without having to deal with jackd management(configuration, manually start/stop, jackd blocking the audio-device(when connected directly to alsa) etc.), and see what works and what not.
WirePlumber 0.4.0
This is the first stable release of the 0.4.x series, which is expected to be
an API & ABI stable release series to go along with PipeWire 0.3.x. It is
a fundamental goal of this series to maintain compatibility with
pipewire-media-session, making WirePlumber suitable for a desktop PulseAudio &
JACK replacement setup, while supporting other setups as well (ex. automotive)
by making use of its brand new Lua scripting engine, which allows making
customizations easily.
I tried to make a reasonably featureful DE based on Sway, and it seems that pipewire is necessary for anything multimedia-related to work on Wayland.
However it insists on having something called rtkit (realtimekit) dbus service. I am planning to write a slackbuild, but firstly I wanted to ask people here. How do you manage to work without rtkit? Just running pipewire from console seems to require rtkit.
I tried to make a reasonably featureful DE based on Sway, and it seems that pipewire is necessary for anything multimedia-related to work on Wayland.
However it insists on having something called rtkit (realtimekit) dbus service. I am planning to write a slackbuild, but firstly I wanted to ask people here. How do you manage to work without rtkit? Just running pipewire from console seems to require rtkit.
Realtime scheduling
Realtime priorities are given to the data processing threads in both the clients and the server.
Since 0.3.44 there is a single module-rt that can use RTKit and fall back to native thread implementation automatically.
The RTKit implementation is potentially better because it can implement a global policy and does not require extra permissions from the client. It however needs DBus and is currently not configured optimally in many distributions. It also does not work with flatpaks because it does not know about the namespace of the thread ids in the sandbox.
Seeing that rtkit is optional and only "potentially" better, it is safe to say that Pipewire in Slackware should already work adequately, right?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
