rack::settings::sampleRate not returning value when compile in windows?

Development
1

Hi everyone,

just wondering if anyone run into this issue? i notice that rack::settings::sampleRate returns 0 when my code is compiled on a windows machine. this works all well when i dev in macOS.

any idea surrounding this? I really don’t wanna hard code sample rate into my code.

any help is appreciated.

Thank you so much.

Best, Jon

2

Hello,

rack::settings::sampleRate is a “runtime” value (evaluation during module run, not during plugin compile).

3

Hi Dominique,

thank you for your response. Yes, i understand that. the issue im running into is that when i use debug to print my sr variable where rack::settings::sampleRate is stored, it’s reporting back zero in my log, thus rendering code down the line to have inf. I didn’t have this issue when i run my plugin on macOS.

i hope that makes sense.

cheers, jon

1 Like
4

Oh yep Jon, I’ve seen you don’t have this issue from MacOS, but from Windows.

Really I can’t help you because I don’t use/have Mac. Hope somebody will help you here!

Cheers from France. Dominique.

EDIT/ADD: perhaps from Windows, the sound system (driver) can’t be established (in case you’re using Windows WDM + ASIO drivers). Like a Rack without AUDIO-x output module, the sampleRate is… zero! (really), and by the way, timings are erratic, until you place and configure correctly the AUDIO-x module into the rack!

1 Like
5

Are you sure you want the setting? Most plugins need to know the actual current rate, but not the setting.

1 Like
6

The current sample rate is given by AUDIO-x module! without it (or if not fully configured), sampleRate = 0 On Windows platform (IDK on Mac or Linux to be honest)

7

Really? The sample rate passed to each process call is wrong?

8

On Windows platforms, yes! (except if fixed in lastest 2.5.2, I don’t have tested). I’m not at home, so I can’t experiment again at the moment.

No AUDIO-x module → sampleRate = 0 Badly/incomplete configured AUDIO-x module —> sampleRate = 0

9

yup i found a solution towards that, not the most efficient but will work out from there. i’m used to initialising with sample rate and buffer size as with how audio plugins do. so the current solution is during the module constructor, i call APP->engine->getSampleRate()

then have an onSampleRateChange function to update if users change in settings.

1 Like
10

I agree, but in this case, is on “runtime” (aka while the module is instanciated in rack), not during plugin compile.

Here : https://github.com/DomiKamu/Ohmer/blob/v2/src/KlokSpid.cpp

Lines 331, 334 to 337…

11

But process get passed the sample time, yes? So you are saying there was a bug where the sample time was infinite?

12

These are cases during initialization, before process() is called, that APP->engine->getSampleRate() returns zero (on Windows). (and apparently some other cases).

I’m expecting Rack at some point to call onSampleRateChanged() once it gets the actual sample rate. I’ve seen a number of sample-rate-dependent modules that don’t implement onSampleRateChanged and hard-code 44.1 or 48k.

process() is absolutely the wrong place to allocate buffers based on the sample rate/time passed to it. That’s what onSampleRateChanged is for.

2 Likes
13

of course. I am questioning why one would want to programmatically query a user setting like that…

14

Yes, I’ve noticed that initial calls to process() may have a args.sampleRate of zero. My solution has been to wait until it’s not zero before using it. This is on Windows.

2 Likes
15

Are Rack’s devs aware of this?

16

Just a quick note here: you don’t need to call onSampleRateChange() from a module’s constructor as Rack does this any time a module is added.

17

So it sounds like the summary is:

  1. There is a bug where Module::process is called with a bad sample rate on startup, maybe only on Windows.

  2. One should never call onSampleRateChange() themselves.

Is that an accurate summary of the issues?

18
    1. Seemingly.
    1. Correct.
1 Like