It has been a long time since I had a serious look at my audio software set, and the Slackware DAW Live ISO image which is meant to showcase all of that software.
Life interfered and priorities shifted.
Now I am looking at 2025 and the Christmas holiday week which precedes it, and am pondering where to put my energy and time. Considering the lack of clarity about the next stable Slackware release (something which really annoyed me in the few years leading up to Slackware 15.0) and the relative certainty that KDE Plasma 6 is not going to be included in that next release, I am not looking forward to kickstarting my obsolete ktown repository for Plasma 6. It would eat up a lot of my time and I am a happy Plasma 5 user.
So, I decided it would be more productive and rewarding to revive the DAW and audio software project.
I will not focus on a refresher of my Slackware 15 based DAW Live Edition. I want to switch to Slackware -current, realizing full well that this may cause new frustrations along the way when stuff breaks as a result of a Slackware update, but I really want to experiment with Pipewire – for sure as a replacement for Pulseaudio but perhaps also as a replacement for the Jack Audio Toolkit. Who knows.
However, I have not been playing/experimenting with Slackware’s sound system since 2022, the whole Pipewire adventure has passed me by. If I want to rebuild & refresh that large set of software, I need to start with the basics and that is to get a low-latency ‘pro’ sound subsystem off the ground that I can understand and adapt to the needs of a Live Edition.
HELP!
Therefore a request to you, blog regulars, to help me understand how to get rid of Pulseaudo in Slackware and replace it with Pipewire. How does Jack still fit in this configuration? Should it remain the main sound server? Should Pipewire replace it, providing the binary API to Jack-enabled applications? Should the choice to have Pipewire or Jack as the main sound server be something you would want to make after login?
Anything you have already mastered and all the bugs and nasties that you have already eradicated, will save me some precious time and give me more motivation to restart the project during my Christmas break. Use the comments section below to describe your challenges, your solutions and your resulting setup; or link to pages / pastebins that contain Slackware-specific information.
And somewhat related, since I am not a musician or audio technician: I want to understand better how to connect the audio software to audio hardware: how do you link up a DAW like Ardour to an external USB sound card, a MIDI controller keyboard, hardware synths, microphones etc.
Some synths present themselves as another external USB sound card as well – how do you deal with that when you already route your audio through your FocusRite Scarlett? It boggles the mind when you have to try and make sense of it when you do not have music-making friends in physical proximity.
Eventually I want to have a working studio in my attic and be able to create music, not just create a music production enviroment like Slackware DAW Live.
I would love to read all your feedback and hopefully it will be enough already next weekend to help me startup when my off-week starts 🙂
Cheers, Eric
I’ve been using just pipewire for the past 1-2 years already. I haven’t removed pulse, but it’s still installed, along with jack. For jack I use pipewire’s jack, and pulse calls are handled with pipewire-pulse. (I figured that a lot is compiled against pulseaudio, and a lot of software still expects it to exist, even if the system calls are handled by something else.) To use pipewire’s jack, one needs a file called “pipewire-jack-x86_64.conf” in /etc/ld.so.conf.d with just “/usr/lib64/pipewire-0.3/jack” in it. Pulse doesn’t run and stays out of my way, so it stays installed. Just the way I like it: seen and not heard. ;^)
I’ve been using qsynth to handle MIDI lately, and it’s not bad.
I haven’t noticed any xruns or the like, but I’ve only been using jack for supercollider. (I keep jack.conf in ~/.config/pipewire, because otherwise it gets clobbered every time pipewire updates. 256/48000 seems to provide a nice low latency for supercollider, but I haven’t been doing anything too crazy with it.
Supercollider: it’s bugged against the version of boost in current, and if you compile it against its own boost, it’ll not copy help documents to the correct place. (This situation may have fixed itself in the month or so since I reinstalled everything after the new hard drive.) It was easier to copy the help documents over to its spot in my home directory manually, honestly. It’s an old bug that *should* be fixed by the new version, whenever that comes out.
OBS: think I emailed my notes? I didn’t have much success with OBS 30 and above, but I haven’t had time to poke at it, either. (There’s an appimage that was sufficient for what I needed for Extra Life Game Day. Not as nice as a compiled version for my system, but it did the job.)
I’m not big on synths (my fingers dislocate on keyboards, and it’s a pain to get them to do non-equal temperament scales of more than 12 notes per octave.) Most of what I do is like csound and supercollider, although I’m switching to supercollider.
Frescobaldi’s dead, I think. There’s some effort to port it to qt6, but I don’t know if it’s in a place that’s usable yet. I’ve been using vscode and lilypond. (vscodium doesn’t work with those plugins.) If anyone’s got a better solution for lilypond, I’d love to hear it. (I like being able to click in a score and have it pop over into that note in the code. For small pieces a text editor is sufficient, but for an ensemble piece over 5 minutes, it’s unwieldy.)
I have seen that most setups are still using jack for realtime, and fully integrating it with pipewire to get the best of both worlds. When I go out live to record bands on my Samsung amd laptop I use a focusrite USB audio interface which works out the box with USB kernel drivers. The focusrite handles setting the db on input for either XLR or 1/4″ Jack and gives me 96000 sample rate with no latency.
Ardour see’s the device via jack, and I setup my session with 4 tracks and set the left and right inputs into appropriate left and rights, this will give me 2×2 2×2 I name 1 master the 2nd backup and at the end I get 2 separate copies of the recording. If the client want’s any FX or mastering added I use the Master copy and then when I share the final result I include the backup unchanged copy as separate file. The focusrite is great as I can listen on headphones to to the pre (before laptop/arodour) and the post (on laptop/ardour) so I can hear whats been recorded and make sure no noise is being picked up from passing threw USB device onto laptop. USB device has simultaneous IO to do this when I measured the round trip is about 8ms to 10ms. Closed back headphones a must. I will have a think about some additional software.
I currently use for my own stuff surge xt bespoke synth qmidiarp qtractor jack-keyboard or mamba plugins via carla geonkick and hydrogen Plus my Novation KS Rack via left n right audio outs and midi via an creative usb to midi device with 4 midi IO’s played with my trusty 76 key CMX midi keyboard connected by it’s own usb output.
Sam, thanks for the extensive description of your workflow.
Sweet. I’ve been looking at focusrite for an eventual replacement of my sound card.
I have a Focusrite Scarlett 2i4 (2nd gen) and very happy with its performance and features. For the more recent generations there’s a nice GUI to manage its functions which are not always reachable via the hardware knobs: https://github.com/geoffreybennett/alsa-scarlett-gui
Oh nice! Yeah, I’d heard the person who was doing the kernel back end for focusrite products got a huge drop of hardware and cash from them. (Granted, it’s cheaper for them to have someone else write the kernel code, but…it’s also a nice gesture when a hardware company isn’t actively hostile towards linux.)
Pipewire seems get a lot of discussion lately, but to me it’s still largely a moving target.
Arch linux has been the best source of information for pulse audio configuration, but there’s little if any other documentation for pulseaudio especially since some pulse apps have been unmaintained for some time now, ex. paman. Configuring pipewire-pulse/wireplumber is a nightmare to me.
Always interested in other people’s take though.
I’ve been running pipewire as my desktop audio daemon for awhile (in 15.0) and have had no trouble with it – the pulseaudio compatability layer works with pretty much everything. I also have jack2 installed along side of it, but I haven’t done any serious audio work in awhile (but also looking to change that. Your DAW distro is excellent!)
I don’t remember exactly how it was I replaced it – I wish I’d kept notes, but I guess that shows how little trouble I’ve had with it, having set and forgotten it.
The pipewire support in slackware-current is supposed to have improved a great deal, so it is promising to hear that for you it’s working fine already in Slackware 15.
What I take from your story (but maybe that’s making assumptions) is to keep Jack2 and compile all audio applications that support it, still against the Jack libraries, and then allow pipewire-jack to create the drop-in replacement layer between Pipewire and all those apps.
I wonder if anyone has looked at qpwgraph as a Pipewire-based alternative to qjackctl.
Yep, it’s good enough to be a replacement. I use it to route microphones connected to audio interfaces to the input of browsers (for conference calls), and it’s really solid for that. Not sure about more advanced usage though
I’ll second that. Qpwgraph is working fine for me in the same way that qjackctl and agordejo have, for connecting a rack of carla hosted plugins with an 8 instance sooperlooper (on pw-jack), and hardware sinks/sources with a 64 sample quantum on a 2013 laptop. I also created a virtual interface in pipewire to consolidate the hardware inputs and outputs for multichannel recording with pipewire-record. Qpwgraph displays the connections when the recording command is issued on a terminal.
Dear Eric,
in the last 4/5 years I’ve running jack2 as my primary audio server. PA is just a jack client. I find this configuration reliable and flexible. I can switch the audio card on the fly (for more complex stuff I use a Behringer UMC204HD usb sound card).
I’ve never dig into the audio stuff internals (except for the Non-DAW code when the original author stopped the development when someone decided, for a very brief period of time actually, to fork the NON-session manager, and I did so mostly for GUI related issues), so I’m not an expert and basically relay on the opinion of guys whose expertise in this field I deeply trust. One of them is Fons Adriaensen who, in the LAD mailing list, from time to time, asks if Pipewire is ready to replace jack and PA [1]. As far as I understand his final solution is to use Pipewire as a jack client.[2]
Now, Fons was a researcher at the University of Parma (Italy) in the Laboratory for Acoustics and Electroacoustics and wrote much code related to ambisonics and, more generally, to linux audio projects. He was doing research on this field, and needed a predictable and reliable system. According to some of his post, at least in 2023, Pipewire was not up to the task.[3]
Three years ago Unfa tried to replace jack with pipewire [4] but came back to jack a few months later.[5]
I really do not know if now everything changed and pipewire is THE replacement for both jack and PA. Still I hardly believe in those pieces of software that pretend to be the ultimate solution for every computational needs: in this case a desktop and a professional DAW. These are two different domains, with different user cases. Personally I’ll stick with jack and when PA will be substituted by pipewire I’ll try to use it as a jack client.
Best,
andrea
[1] See in 2022: https://www.mail-archive.com/linux-audio-dev@lists.linuxaudio.org/msg20226.html In 2023: https://www.mail-archive.com/linux-audio-dev@lists.linuxaudio.org/msg20396.html
[2] This is from August 2024: https://www.mail-archive.com/linux-audio-dev@lists.linuxaudio.org/msg20631.html
[3] See this post by Wim Taymans (and the answers by Fons) https://www.mail-archive.com/linux-audio-dev@lists.linuxaudio.org/msg20409.html
[4] https://www.youtube.com/watch?v=q7XrrBXIzfg
[5] https://www.youtube.com/watch?v=RvWgm6aZTQA&t=520s
Thanks Andrea for you thoughtful comments and for sharing the links to lots of stuff to read through and watch.
I switched to Slackware 15 stable for music production as i wanted a very stable system for live performances. I have been using Pipewire on an arch system and on debian too. My experience has prooved me that Jack is unbeatable for stability and latency..
Is there anything you miss in my packages (apart from newer versions) or the way the DAW environment is configured?
Looking at the few comments, there is no consensus about Pipewire being able to replace Jack, but fore sure Pipewire can replace Pulseaudio while still deferring as a client to a Jack audio server.
At the moment, I am inclined to keep building Jack and continue compiling audio software against the Jack libraries. That way, the choice remains with the user: either go with Jack or else install pipewire-jack, and let Pipewire take over from Jack as the main audio server.
Perhaps it’s something that I can put into a script and call it ‘jack2pipewire.sh’ and ‘pipewire2jack.sh’…
I tried indeed pipewire as a replacement of pulseaudio in xubuntu, than i installed jack and it worked nicely! so yeah it would be a good alternative and providing both options would be the way to go.
Regarding configurations i tend to do as little as possible
1. performance mode (i have a script that starts with jack)
2- threadirqs (in grub)
3- since by default slackware adds the user in the audio group i just add:
@audio – rtprio 95
@audio – memlock unlimited
to: /etc/security/limits.d/audio.conf
and thats all actually.
this has prooved to be perfctly stable with no xruns on my thinkpad t490.
I haven’t had any issues with SlackwareDAW either
P.S. it would be nice to have this: https://github.com/baconpaul/airwin2rack/releases/tag/DAWPlugin running in slack…
I’ll put those Airwindows on my TODO list.
Hello!
I m using https://github.com/dimtpap/coppwr as alternative of qjackctl.
https://pasteboard.co/NVFAcQmLSAxO.png
I have my own slack build system https://github.com/rizitis/PLASMA_WORLD/blob/main/AthOS/REPO-AthOS/coppwr/coppwr.ini but it can easy be a traditional slackbuild if you want to build and use coppwr…
Hi Yiannis,
Interesting tool, I have to add coppwr to my TODO list.
I have started the task of updating all 140+ packages mentioned in http://www.slackware.com/~alien/tools/templates/daw.template . Perhaps some of those have been obsoleted, or absorbed into Slackware, I’ll find out as I go along.
I have finished building 46 packages on Slackware 15.0, some I had to create as new dependencies for newer releases of these DAW packages. I.e. 100 to go.
And then building them on -current which will probably require some additional patches… and then 32bit which again will be a potential codebreaker.
It’ll take a while yet. And so far I have been compiling but not actually tested any of these programs, that too may give surprises.
Another update.
I have uploaded a batch of supporting packages into my repository. These fall into three categories:
1) packages that became part of Slackware-current but I need them on Slackware 15.0 now, so I used Pat’s -current build scripts and built packages for Slackware 15.0 from those.
2) packages that have become a bit stale in Slackware 15.0 and are causing more and more build failures for modern software. I updated these to their latest releases (as found in slackware-current). They are safe to upgrade to on your Slackware 15.0 computer.
3) packages which are build-time dependencies for some of the DAW packages.
I am now compiling 32bit versions of the 75-or-so 64bit packages that I already have. All of that was built on Slackware 15.0 but when the 32bit packages compile without errors I will move on to -current. I created a build-all script with dependency resolution which is now chewing its way through the software list and I will have a look at the results tomorrow morning.
It looks like the software which I already compiled runs just fine.