Rendering sample rate is not the same as the audio sample rate

Development
1

I’m posting this here because I was surprised that something I thought was true is not. I thought when I changed the audio sample rate in the VCV Audio module that my override of onSampleRateChange would get called:

    void onSampleRateChange(const SampleRateChangeEvent& e) override
    {
        INFO("new sample rate = %f", e.sampleRate);
    }

and that subsequent calls to process would have a new sample rate reflected in the parameter ProcessArgs::sampleRate.

It turns out that my module is always rendering audio at 44100 Hz, even when I start up with the Audio module set to a different rate like 8000 Hz or 48000 Hz, or when I change the rate manually while running. With the above code, the log shows a single call at startup, no matter how many times I change the sample rate after that:

[0.323 info src/mymodule.cpp:81 onSampleRateChange] new sample rate = 44100.000000

I suppose something else in VCV Rack is resampling the audio for the driver, because I can definitely hear loss of higher frequencies when I change audio to 8000 Hz.

Maybe this is platform specific? I’m on Linux and using PulseAudio.

I guess my only concern is, I would like to test my module at different sample rates to make sure my DSP algorithms can handle a wide variety of rates correctly. But I can’t figure out how to make VCV Rack change the sample rate it asks my module to render at.

Any ideas?

2

Geez - that doesn’t sound right.

I’ve got to believe onSampleRateChange is working properly for me. I have modules with oversampling and the band limiting frequency cutoff is highly dependent on the sample rate. The oversampling seems to work properly for me at all sample rates. I’ve tested my modules on Windows and Mac

3

Thanks @DaveVenom. Your comments motivated me to try running my code on Windows. With Windows/WASAPI or Windows/DirectSound instead of Linux/PulseAudio, it acts like we would expect: every time I change the sample rate, I get a log message from my onSampleRateChange with a matching value.

So now I know I need to do sample rate testing in Windows, at least for the time being. This is an important quirk for my fellow Linux-based developers to know.

1 Like
4

I am not at my machine to verify this, but IIRC the sample rate of modules and the audio engine runs at is set in the main menu Engine – Samplerate. This is not the same as the sample rate of the audio output, as set in the audio module. Changing the sample rate in the main menu should call onSampleRateChange() .

2 Likes
5

I dont like posting untested comments, so I have started to do some testing. The code I have used is

 void onSampleRateChange() override {
        DEBUG("SampleRateChangeLogger::onSampleRateChange sampleRateAPP %f\n", APP->engine->getSampleRate());
    }

On a Mac m2, The first time I select an audio interface, Core Audio Macbook pro speakers, I get a log entry with the selected sample rate. Any additional changes in the audio module, to sample rate, or audio device do not call onSampleRateChange(). changes made in the Menu-Engine-SampleRate are reflected in the log.

Testing on Ubuntu 22.04.2 LTS with both pulseAudio and Alsa I only get log statements when changing the sample rate from the main menu, not when changing the audio module settings.

Testing on widows 10, only logs when changing the sample rate in the main menu.

I have gone back and tested all os, and the only time my module logs an onSampleRateChange() when changing the setting in the audio module on any os, is if there is no audio device selected from startup, then the initial setting will propagate.

6

Thank you for explaining this! I had never noticed that option up there before in the main menu. This is what I was looking for, and I’m happy that I can test my DSP algorithms at different sample rates while staying on Linux.

1 Like