does any drop-in-replacement work (pulse/jack)? latency? crashes? is it production-ready?
I’m actually glad my system runs pretty stable now after much tweaking and tuning and I’m still learning the basics of VCV, which will take a few more years. Would be nice to hear from someone who tried this.
are you experienced?
It’s not production ready yet apparently. I’ve heard it will be adopted in Fedora first but don’t know when that will be.
If it can help: I collected some thoughts about my setup and Jack/Alsa here: Rack on Linux with relatively old hardware: a personal update - and in case you missed it, many Linux / Rack users wrote their experiences here: Current best live Linux distro for audio/studio enviroment: thoughts?
thanks, I’ll stick to my current setup then and concentrate on making strange noises for now
Fedora 34 (released April 27, 2021) first adopter: Notable changes for desktop users :: Fedora Docs
a bold move. just upgraded to lubuntu 21 and I’m tempted to try this out, hope it doesn’t break too much
I’m running openSUSE Tumbleweed (rolling release) and recently switched to pipewire (version 0.3.30). VCV Rack runs smoothly as a JACK client. I just need to manually connect the outputs to a sound card in Catia.
I recently upgraded to Ubuntu Studio 21.10 and decided it was time to try Pipewire. There is a PPA available for Ubuntu and Debian, makes it pretty easy. Followed the instructions from the link below and managed to get it working. Took a couple reboots to get everything to initialize properly, but seems to be running smoothly now, including VCV Rack. Thought I would share for those thinking of taking the plunge.
(edit: I should say I wouldn’t call it “production ready” yet. It is still a work in progress as far as making everything seamless, but worth checking out if you don’t mind a little tinkering.)
Yeah it’s been painless and actually offers much more flexibility, I love it. The only thing for me is that Rack now starts with a number like ‘VCV-Rack 98’ and the number changes so I can’t get it to autoconnect any more using the qjackctl patchbay function.
That’s odd. You might have an old/buggy PipeWire. This snapshot is VCV Audio-8 module and qjackctl graph window showing the module connections (obviously running PipeWire here). The module remembers my selection and auto-connects it to the same ports every time I start VCV-Rack. As you can see, I’ve got no weird named ports.
Without jack in that I’m not using the jack interface. I wish I understood what was going on better to be able to provide something more constructive, but I don’t. Jack isn’t showing a device to use in VCV. I selected the default alsa device and it worked, no glitches or underruns or anything, so I’m going with it for now. Haven’t had the time or mental energy to figure out the jack device part yet.
Yeah I’m not sure why it’s happening either, I have the latest pipewire. I was messing around with my soundcard profile in the KDE volume applet so that might have done something but I’m not sure where to even start fixing it.
Just tried using alsa as output in Rack and that fixes it so I guess it’s something to do with jack implementation or some jack setting somewhere.
Hi there, also trying to switch to PipeWire here.
I have high hopes for it to solve the decade old issue of needing both consumer and professionnal level programs running at the same time.
I have to say that my setup is pretty default and works fine with Bitwig set to use pw’s jack implementation.
My issue is with Rack and, most of the time, Firefox that might play some music or even just notification sounds from time to time. It seems as though firefox would “steal” the audio access from Rack which would then hang if I’m to click around the audio settings a bit.
In that situation, upon closing Rack hangs on that message:
[10,131 info src/rtaudio.cpp:146 closeStream] Stopping RtAudio JACK device 0
I keep switching to pipewire and then going back and the last time I did it I had exactly the same problem with bitwig as you’re having with Rack. I think you need to run the pulse module with the same block/rate settings as the Jack module.
However, I think this might be the real answer. Let me know if that fixes it because I would like to go back as well but that bug/feature was really annoying.
Thanks for the reply, I will keep this solution in mind.
Are you on Debian or Debian-based by any chance? If so, is the process for reverting to Pulseaudio simple enough? I’m considering doing that.
So far I fixed it by using the ALSA driver in Rack’s Audio module, the “default” device is a loopback to pw, like with pulseaudio and I get latency that is decent enough for working with midi controllers.
I’m on arch but I don’t think it makes much difference. It is simple to revert either way, just disable the pipewire and pipewire media session/wireplummer services and enable pulseaudio.
I used the alsa output when using pipewire as well, think I couldn’t get it to work with the jack output but the result was good for me although I didn’t do much with controllers.
FYI, PulseAudio support in Rack is buggy. It’s a touch and go working with native PulseAudio and completely broken with PipeWire-pulse. The issue stems from a verified bug in RTAudio that was already fixed in later versions of RTAudio, but unfortunately the version vendored in Rack is old (more than a year) and buggy. Case was opened with support@ to upgrade RTAudio and is pending. JACK (either native or PipeWire) should really be the only audio interface to be used currently. Anyone interested in this bug, here’s the issue tracker: RtAudio PulseAudio apps randomly fail to scan input/output devices (consistently on pipewire-pulse) · Issue #304 · thestk/rtaudio · GitHub
Thanks for that information.
Did you report this yourself to support@ to open that case? If you can, let us know how it progresses!
(offtopic: +1 again for more transparent support and issue tracking … )_
I used jack before switching to Pipewire. I’m on Debian Testing and followed along this wiki page, including replacing the jack libraries with pw’s. For now this setup is unreliable in VCV Rack, as I said I’m using the ALSA driver as a temporary workaround.