I have a signal chain which is not used for performance, unless recorded music playback is considered “performance.” Latency is not an issue. I’d like to understand when and how GP does sample rate conversion.
If I set the sample rate to 88200 Hz in the “Audio Properties…” menu, and the Windows playback device is not playing at that rate, does GP resample it? Even if the sample rate is the same, does GP change the sample type (bit depth, int16, float, double, etc) to something other than the input device’s bit depth?
How does GP negotiate sample rates and bit depth with and between plugins? Can it ask for the same rate as set in audio properties, or does it use something else internally? Assuming plugins may or may not support the desire sample rate, what does GP do? Can resampling be avoided?
What sample rate and type are used for the output? Can the input and output rates be set to different values? Ditto for bit depth/type.
Finally, which sample rate converter (OSS codebase such as SSRC, home grown, etc) does GP use. Is it user-configurable? Is there any way to select dither PDFs or noise shaping curves? Numeric precision?
You specify what sample rate in GP you want from the list of rates that the audio interface claims it supports and GP will then tell the audio interface to run at that rate.
Plugins have to run at that same sample rate, that’s how it works. If the plugin doesn’t support the desired rate, you’re out of luck.
Not sure what you’re trying to do but this is how audio plugins work in general.
It may be that simple, but may not be, which is why I ask.
For example, and IIRC, Pro Tools AAE locks the sample rate for each processing graph (plugins, etc, per track and bus, etc) at a single, consistent session sample rate. (TDM, as used in their older products, doesn’t even specify the data format for each device’s time slice in the stream.) On the other hand, it converts all input data to float: either single 32-bit or double 64-bit precision. Additionally, it can negotiate with VST3 plugins, so that a high precision 64-bit session may convert to 32-bit for a plugin that only accepts single precision. Complicating matters, some plugins with optional “high precision” modes may resample 32-bit inputs and use 64-bit at higher sample rates internally. I don’t know if they’d advertise 64-bit only in the setup negotiation and PT would do the SRC.
There might be sample rate or format conversion in GP for other reasons to, such as to ensure reliability on low power CPUs. Anything is possible.
I don’t want to dismiss your answer out of hand, dhj. But I must ask if you’re one of the developers who knows the code. I have no idea who’s who in this community.
I’m evaluating GP as a VST host to improve poor quality recordings on the fly. Remastering on the fly? And for the fun of it – the Dorrough meter plugin atop the rack makes me happy!
There are umpteen possible stages in the signal chain where SRC could kick in. I don’t want quantization noise, or any other artifacts caused by, for example, poor/no anti-aliasing filters, to accumulate unless absolutely necessary. There’s no noisy live music venue with less-than-optimal acoustics to mask low level garbage.
I’ve managed to get this running under Windows glitch-free with everything locked at 24/88200 and roon doing the SRC up front as necessary. Every other VST host I evaluated besides GP has either been inappropriate for my purpose(s), or was unreliable.
Yes, what @dhj and @Frank1119 wrote is correct.
There is no SRC, all internal audio routings process the same SR using float 32bit.
The only exception where SRC is used is on streaming audio with external DAW using GP Relayer plugin. If the SR mismatches between the instances, then SRC automatically applied behind the scenes. But that is relevant only to GP Relayer plugin.
