VCV standalone disrupts audio driver when started

When I start VCV standalone 2.0.3b it disrupts the audio on my system. (Win 10, Focusrite scarlet 18i20.) In my template setup the audio module is set to 44.1k but on launch VCV always seems to want to change that to 48k but then reverts to 44.1k. I thought I’d read about this issue somewhere else, but I can’t find it. I can load the template without audio module, but then I get the same behaviour when choosing the asio audiodriver. Any tips, tricks, solutions, suggetions?

1 Like

I’m having the same phenomenon with my RME AIO, already reported here. I was requested to contact support but received no answer yet.

It is important to mention that the cracking does not occur in the parallel installed v1, the initialization takes place there seamlessly.

I did the same with the same result.

Same experience: no problem with v1. So it seems to be a v2 issue. Let’s hope it’ll get resolved soon(er or later), preferrably sooner, of course.

I reported this same issue soon after the prerelease of Rack 2, but no reply from support.

There was a fix relating to the audio module in 2.0.4, have you tried that version?

This was reported by someone else as maybe “audio click”? But they also thought it was 48/41 issue.

Installed 2.0.4 pre, same issue.

The only “solution” I found so far was to hack rtaudio and replace the relevant hard-coded 48000 with 44100 and then compile the Rack myself.

But … in Rack v1 rtaudio had the same hard-coded 48000 values and it works fine with Rack v1.

It seems that there’s some bug in the code that initializes rtaudio without setting the desired sampling-frequency rigth at the beginning.

This seems to also disrupt audio output levels in patches where the audio device has to be selected in the VCV Audio module before a patch with a clocked part is started. I’m of the belief there’s an initialisation bug somewhere in that module.

https://community.vcvrack.com/t/prism-rainbow-need-mac-linux-users-to-test-a-patch