EDIT: The original proposal was for the implementation of a (default-enabled) safety-guard. From discussing on #juce on TheAudioProgrammer discord, there is some contention regarding the proposal. Therefore, I reduce the proposal, and instead propose no more than that the JUCE team discuss the options for implementing such a safety guard.
I have damaged my eardrum with this code:
void audioDeviceIOCallback(
const float** inputChannelData, int numInputChannels,
float** outputChannelData, int numOutputChannels,
int numSamples
) override
{
...
If I don’t explicitly zero the output buffer, occasionally (for me 20%+ of runs) the output buffer is not zeros, and ths makes such a loud static sound that even on macOS MINIMUM volume it is dangerous.
I had no idea it was possible to drive headphones/mac-speaker this hard. Surely it must risk destroying the speaker.
So, now it seems I have a perforated eardrum.
So please consider making this change:
(EDIT:)
myAudioDeviceManager.addAudioCallback(
newCallback,
false, // zeroOutputBuffer : optional, default true
false // checkOutput : optional, default true
);
Or adding 2 flags to .initialize
:
myAudioDeviceManager.initialise(
1, // numInputChannelsNeeded
2, // numOutputChannelsNeeded
nullptr, // XML
true, // selectDefaultDeviceOnFailure
device, // preferredDefaultDeviceName
&deviceSetup // preferredSetupOptions
false, // zeroOutputBuffer : optional, default true
false // checkOutput : optional, default true
);
Or even adding members to
auto deviceSetup = AudioDeviceManager::AudioDeviceSetup();
deviceSetup.sampleRate = 44100;
deviceSetup.bufferSize = bufSize;
deviceSetup._DANGER_zeroOutputBuffer = false; // defaults to true
deviceSetup._DANGER_checkOutput = false; // defaults to true
Maybe the last pattern is cleanest, as it now becomes impossible to remove the (now) default protections without realizing what they are doing. Any code containing these overrides is explicit. Warning-via-code > warning-via-doc.
Now this is non-breaking, and an engineer concerned with optimizing performance could manually elect to disable the safeguards.
The key point is that they would need to explicitly write , true, true
in order to disable the safeguards, which means they have read the API doc for the method, and understand the implications.
Mattijs on TheAudioPrgrammer Discord has offered a shim for preventing this.