Linux, Pipewire & Block Size

I’m running Arch Linux (technically Garuda, but using the latest kernel, etc) & pipewire (with wireplumber). When I use Rack I have to bump the block size up to the highest setting to avoid artifacts/stuttering. Sometimes I can accomplish 1024, but any lower and the audio coming out of Rack immediately goes bad. I have a pretty powerful laptop (8 core/16 threads, nvidia gpu, 64GB memory, etc); frame rate is at 10hz; I’ve tried it with any number of threads and that doesn’t make a difference. Is there something I can do in the pipewire configuration to improve this?

Also, fwiw, I can run at a block size of 256 in Bitwig with no skipping or artifacting.

Seems like it might be something related to the Pulse Audio compatibility wrapper. I just tried launching Rack via pw-jack; changed the driver to Jack and block size to 256 and it sounds great! I’ll have to test latency with my MIDI controller a little later, as that is the motivator for solving this issue.

1 Like

If you haven’t looked at it already, you can also try changing the number of threads to as few as possible.

This seems to have occurred a couple of releases ago and is yet to be addressed (I’ve informed support). I used to get away with 128, now I need a minimum of 1024.

This issue may be related to a glitching problem I found in RtAudio, which VCV Rack uses for sending audio to PulseAudio. I was able to fix this issue on my system, and I submitted this fix as a pull request to RtAudio three weeks ago. So far I have not heard back from them.

It is possible to build VCV Rack from source, while including my fix to RtAudio, to eliminate the clicking/popping sounds. That is how I run it on my Linux system. Here are instructions for building Rack with my fix if that is something you want to try.

4 Likes

Good man Don!

Thanks! I’ll have to give this a try!

1 Like

I’d be very interested to hear about the results! Please let me know if you run into any problems with the build process and I’ll do my best to help.

Just came back to this, sorry I never replied previously! My system is actually using pipewire, not pulse, so rtaudio is not a factor if I understand correctly.

Hey Joe, in the time since I wrote this, I found out that the best fix is not to make a change to rtaudio after all. Instead, it works better to change the number of audio buffers Rack passes to PulseAudio from 2 to 4.

When you use pipewire, what audio layer do you select from VCV Rack? Is it Jack? A similar fix may be possible there, without incurring the extra latency.