I still can reproduce this problem with today’s git version. If I write a buffer alternating between -1.0f and 1.0f to a 16-bit wav file, all samples end up as -32778.
This still occurs in PPMulator, and here’s the code I used to double-check it:
AudioSampleBuffer alternatingBuffer(1, 100);
for (int i=0; i<alternatingBuffer.getNumSamples(); i++)
float* sample = alternatingBuffer.getSampleData(0, i);
*sample = (i%2) ? 1.0f : -1.0f;
File appFolder = File::getSpecialLocation(File::currentApplicationFile).getParentDirectory();
File wavFile = appFolder.getChildFile("test.wav");
FileOutputStream* fos = new FileOutputStream(wavFile);
(wavFormat.createWriterFor(fos, 48000.0, alternatingBuffer.getNumChannels(), 16, StringPairArray(), 0));
afw->writeFromAudioSampleBuffer(alternatingBuffer, 0, alternatingBuffer.getNumSamples());
We had a “great time” today with a similar issue when checking the reference files created with ppmulator. At some levels (for example -20dBFS / 0.1) the peaks in the wav file are not symmetric (min=-3277 and max=3276). ToneGeneratorAudioSource doesn’t look responsible for that, so it’s probably a similar rounding/conversion issue in the juce_AudioDataConverter.h. This may sound nitpicky, but for sine reference signals it’s really odd to have an dc offset.
It would be great if you could have another look at both the clipping and rounding issue. We tried to debug this on our own, but couldn’t follow all the casting and rounding involved there. What’s happeding in AudioData::Float32::getAsInt32LE() seemed odd to us (as data seems to hold a valid int32 value, so why interpret is as float?), but probably we just didn’t understand the context right.