No, it’s not a love letter, but just a sharing about my last experience with Pipewire.
I recently switched to Debian Testing (Bullseye) and I wondered: Why not try pipewire and see what happens since Fedora is about to default to pipewire on 34 version?
Yes, it’s still at an early age and maybe we should refer to it only as “beta”. Does it change anything for Ardour now? No, but still it did surprise me, even at this early stage, be able to see Alsa working flawless under 64 samples, without xruns. I can even set 32 samples right now if I wish to, but this low latency setting produce some xruns from time to time on my laptop. Never before have I been able to achieve 64 samples without a rain of xruns in all the distros I prepared for audio production before, even after the realtimeconfigquickscan script check “good” to everything. I tried a lot of tweaks on linux until today but none has ever succeded compared to Windows performance with manufacturer driver of my usb interface. I’ve been working with 256 samples on linux since so because that was the only way to avoid sporadical xruns. I see something promising about the future of pro audio on linux and from pipewire itself, it is evolving really fast and I have this feeling this will put things on an equal footing between linux and others ecosystems some day.
I installed pipewire-audio-client-libraries via Debian experimental repository and I mean last 0.3.24 version with that. Please note pipewire isn’t ready and you’ll find a notable lack of functionalities so I must remember you may have to configure many things via terminal or conf files. I need to stop pulseaudio using systemctl --user stop command but in an overall it works nicely. I also should mention that pw-jack doesn’t seem to deliver the same performance advantages I got with Alsa for now. Oh, and I can’t change my sample periods if I start Ardour using Jack/Pipewire if not with the pw-jack -p ‘period’ ‘ApplicationName’ command before startup. By the way, pipewire-pulse works fine.
Perhaps this is the end of fragmentation?
That’s all. I am very excited about what is coming.
See you.
I also am using Pipewire, but on Manjaro and I use the pipewire-jack-dropin packages to make it so I don’t have to open the terminal as much.
Ardour does have a periods configuration somewhere, but I can’t remember where. I’ll find it when I’m back at my audio production computer (away from home right now as I type this).
My experience has been a little more mixed. I’ve been testing it on and off for a while, because JACK+Pulse has its own set of issues (DSP load from Pulse passively is lame, lack of configurability and the pulse bridge sometimes crapping out and forcing me to log out and back in), so I’m using just Pipewire.
For those wanting to try this
Use the ALSA backend in Ardour, and export projects using the realtime export function. This bypasses the freewheeling function that Ardour uses in JACK to export audio, which is currently not implemented within the pipewire framework. They’re working on it, and believe me, I’ll be the first to shout it from the rooftops when it happens
Expect to use QJackCTL or Catia as your connection manager. Something about Pipewire, expect connections only to appear when using sound, which is a little bit of a nuisance if you’re trying to route audio someplace different than normal.
You’re going to need to dive into the configuration files to set up Pipewire optimally. If you are able to make sense of the documentation (it was a little technical for me), I’d love to know how to configure it a little more granularly. From what I understand, there is a way within the configuration files to set it up so applications automatically open with a certain period size, which would make life so much simpler.
In general, I think we’re at least a year out from mass pipewire adoption. I rarely hear of people doing audio production in Fedora, so I suspect there will be pushback on adopting it for AVLinux and Ubuntu Studio at least. Currently as it stands, Pipewire is a system package in Manjaro and looks very scary if you’re trying to uninstall it because it’s now so linked into the OS.
As a final note, the pipewire devs have been super responsive, including reaching out to me after I reported an issue with x-runs galore while using Pipewire and Carla to practice to ask if I was still experiencing the issue after they’d made some changes. If you encounter bugs, please report them to them - they really want to see that vision that @Vivantart is describing happen.
Yes, but you can’t change it on-the-fly even if you “stop” jack. It’s something related to pipewire and I remember reading something on their website saying “you can’t change it yet” so it looks like they plan to implement this functionality very soon.
I didn’t try it yet… What happens if I don’t use realtime export?
Well, now, if I use Ardour+alsa, I can’t watch youtube(for ex.) because alsa kinda “captures” audio device… I thought this is expected by design, but I’m not sure now…(if we have pw intermediates, so it should mix sounds, right?). At least muscore + alsa works without hanging youtube… hm…
Using ALSA to access the actual hardware device always requires “exclusive access”, whether it is Ardour, Musescore, or Firefox doing it. So, if you are using software that demonstrably does not force exclusive access, then you know that it’s not using ALSA to access the actual hardware device.
A lot of software will just open the “default” ALSA device, which on many Linux systems these days is not a hardware device at all. Often, it’s the pseudo-device created by the PulseAudio server. This therefore allows several different applications to “use ALSA” at once, but it is just acting as a layer/bridge to PulseAudio (before ultimately going back through ALSA to an actual hardware device).
Why would you want to watch youtube while recording or mixing or working on a production?
Ardour/ALSA requires exclusive access so that no other application can change hardware settings (samplerate, buffersize, etc) while Ardour is using it. Otherwise reliable IO, capture alignment and low latency cannot be guaranteed. For that reason Ardour/ALSA also refuses to use virtual or pseudo-devices.
For playback only, you could use Ardour’s pulseaudio backend.
This is a scenario that happens more often than you might think…
You want to email a mix to somebody and check it before you email… you want to watch a plugin tutorial or check what the solo or chords to a song are while you’re working in Ardour, you want to grab a bit of Audio online and record it into your Ardour session… I’ve done all of these things and for me it’s the only reason I still hold on to using JACK at all.
Exactly! For me video lessons is the most efficient way to learn such kind of stuff. Couple months ago I didn’t know what DAW is at all. Ardour is my first one, to be honest…
Wow! Things are bit more complicated that I thought initially … Thanks for explanation!..
@x42@paul
In the future it would be worth having native support for Pipewire API on Ardour?
Doesn’t CoreAudio (Mac) do this already for 10+ years?
That’s something people are discussing out there… I think everyone hopes that PipeWire could make linux reach out to the other operating systems at the forefront when it comes to pro audio and consumer audio.
If pipewire gets things right, there will be no native API. Applications will just see it as JACK or ALSA device.
This is why pulseaudio failed. PA never succeeded to expose a usable ALSA device nor reliable bridges, while at the same time pulseaudio had a native API that worked.
I don’t think this is quite right. PA’s pseudo-ALSA device works perfectly fine for most desktop purposes. It doesn’t work for all purposes, and that’s certainly one of the issues.
- crush on startup
… Thanks for explanation!..