Possible bug in audioPlaySoundFrame

[Gerwin2k]

I was building a Win32 version of the latest source. There was a consistent crash whenever the first sound was supposed to be played. (music was fine). I bisected the cause to be introduced in February 2023. Below is the cause commented out, and replaced with the earlier logic, which does seem to work: no crashes, sound is fine. Actually it seems to sound a bit better then the current official x64 binary, where i hear some sound interruptions.

TFE_Jedi\IMuse\imDigitalSound.cpp / function audioPlaySoundFrame

// Read additional samples, but only update the offset by the base number.
// This is required since the results might be interpolated on upsample.
const s32 baseReadSize = min(bufferSize,                     data->chunkSize);
const s32     readSize = min(bufferSize+IM_AUDIO_OVERSAMPLE, data->chunkSize);
s_audioData = ImInternalGetSoundData(sound->soundId) + data->offset;
// GB 2023 - guilty change for audio crashes since February 2023
//audioProcessFrame(s_audioData,     readSize, offset, sound->volume, sound->pan);
audioProcessFrame(s_audioData, baseReadSize, offset, sound->volume, sound->pan);

[classilla]

This seems to fix #266 for me. Nice find.

[luciusDXL]

Thanks for the report. Though it is supposed to read those extra samples in order to properly upscale the audio. So I will have to look into it further.

[luciusDXL]

Ok, I found the issue. The oversampling was correct, but the buffer was increased by the oversample amount - but these are supposed to be stereo samples, which means the value should have been increased by x2. So it was reading/writing past the end of the buffer... Thanks for pointing out the issue, it was probably responsible for "random" crashes even on Windows.

This should be fixed in master now.