Using RTAlloc/RTFree and accessing sample rate

Development
1
  • Is there a way to to RT allocation (using RTAlloc) outside of a context where the mWorld field exists? (that is in a Unit ?)
  • Is there a way to access the current engine sample rate in a C++ coded UGen, that is a init time ? (modifié)
2

Regarding the RT alloc functions, they always need a pointer to a valid World. In some of my code I hold a global pointer that is initialized when the UGen is being created ( _Ctor stage).

Regarding the sample rate, you can retrieve it from a World: unit->mWorld->mSampleRate.

3

Thanks. But I would actually need to use mWorld before the actual _Ctor stage. Same for the same rate. Can I possibly just use a stack allocated Unit like this:

Unit unit;
mydsp* tmp_dsp = new(RTAlloc(unit.mWorld, sizeof(FAUSTCLASS))) FAUSTCLASS();
4

In what context are you calling this code? In PluginLoad? I am afraid you really have no access to a valid World in that case. Using a stack allocated Unit won’t work either, as that would not be the correct World where the rest of the server allocates stuff. Additionallly, you’d have to initialize the allocator yourself in such a case, which won’t be done by just stack allocating a Unit.

By the way, if this code does not need to be allocated in the real time thread, as it would be for a _Ctor function, I would just use standard C++ new / delete without SC’s allocator.

5

If you don’t have access to World *, you’re not in a realtime context, so there’s no need to use RTAlloc and friends.

Maybe describe what you want to achieve, then we can suggest possible solutions.

6

A bit off-topic, but note that (lib)scsynth actually supports multiple server instances (that can even be run in parallel), that’s why the per-instance state is stored in the World structure. A prominent example is SuperColliderAU. Storing the mWorld member in a global variable won’t work in such applications.

In practice, it should work fine within the standard scsynth and supernova server applications, as they only ever use a single server instance. (In fact, supernova itself is really a singleton and doesn’t even support multiple instances.) I just wouldn’t recommend it :slight_smile:

@vitreo12 is very likely aware of this, but I just thought I should point this out to other readers.

7

Yes, this init code is done in PluginLoad. See the code here faust/supercollider.cpp at master-dev · grame-cncm/faust · GitHub and currently using new/delete.
The real DSP is then allocated in Faust_Ctor (see faust/supercollider.cpp at master-dev · grame-cncm/faust · GitHub) using RTAlloc/RTFree.

We have an user complaining for dropouts in init. So this was the reason to try using RTAlloc/RTFree also in load and initState.

8

Note that PluginLoad is executed when the server loads the shared library before the audio thread is even started, so that is most likely not the reason of the dropouts experienced by your user.