Correct. See here from the Unity forums: “You can use stereo or mono signals, but be aware that most spatializers will just mix the signals before applying spatialization.”
I haven’t tested this in detail, I’ll do some research, but this down mixing could cause some glitches.
Unfortunately using a mono output in Csound won’t reduce CPU usage by half.
I’ll explain why later on.
Unfortunately no. As of CsoundUnity 3.4.3, during initialization sr and kr are set to AudioSettings.outputSampleRate:
Csound6.NativeMethods.csoundSetOption(csound, $"--sample-rate={AudioSettings.outputSampleRate}");
Csound6.NativeMethods.csoundSetOption(csound, $"--control-rate={AudioSettings.outputSampleRate}");
Csound6.NativeMethods.csoundSetOption(csound, $"--ksmps=1");
We found this to be the only way to behave correctly at that time (so different kr values were producing garbage audio output). I’m happy to take a look now to see if it can be done with more recent Unity versions.
So with the above context, I’ll explain a bit how CsoundUnity works so it will be hopefully clearer if the number of channels affects performance and also why we should be able to change the kr:
In the OnAudioFilterRead callback, CsoundUnity receives a block of samples from the Unity AudioSource (usually 1024 per channel).
The number of channels we receive depends on the Default Speaker mode in the Unity Project Audio Settings. Yes it’s a global setting.
So if you set that to Mono we receive 1024 samples and numChannels is 1, for Stereo we receive 2048 samples and numChannels is 2. Any other setting (the surround ones) gives back 9182 samples and 8 channels.
The samples come as interleaved meaning that sample[0] = L and sample[1] = R and so on.
We iterate through the samples increasing a counter.
This counter is reset every time a PerformKsmps is executed.
For every tick of the counter, we iterate the channels, for each we set the Input Sample (to Csound) and grab the Output Sample (from Csound) and we write back in the samples array we received with the OnAudioFilterRead callback.
Every time this counter is equal or bigger than ksmps (always 1 as of today), we call PerformKsmps .
This means that, in a stereo scenario, every 2 samples received from Unity, we call PerformKsmps.
So we’re always running at full resolution!
Being able to control ksmps could surely allow us to optimize things.
Instead, apart from avoiding potential glitches caused by the spatializer messing with stereo files, there’s no real gain in using mono output from Csound as we are filling couples of stereo samples with the same mono signal. But yeah I guess on the Csound side it will be less demanding handling one channel instead of two. Thoughts @rorywalsh?
Soon I will have a look at the possibility of changing the sr and kr