This changeset fixes 2 minor issues:

• The sample rate used by the sound effects example was incorrectly using the sample rate of the source audio data and not the sample rate of the playback device which is the sample rate of the data passed to the processing callback
• The size of the audio frame buffer that was automatically chosen by miniaudio for higher sample rate devices would be so big that playing very short audio clips would not output any audio until the buffer is filled entirely at least once

Miniaudio organizes sounds into a node graph. Data is recursively pulled from the sink (the audio device) back to the sources traversing the graph node by node. Because we are using the miniaudio engine for special effects (surround, doppler, etc.) the nodes are engine nodes as well. The engine is initialized to process data at the same sample rate as the device it is attached to. This means that as soon as data is read from the source e.g. an audio file it is converted into the engine/device format before it is sent through the graph.

SFML's support for audio effects processing via callback is implemented by a custom node we insert into the node graph right after the sound source. This means that audio data passing through our effects processing node will already be in the device format since conversion was performed in the source node. Before this change, the sound effects example was incorrectly using the sample rate of the source data instead of the device sample rate to perform filtering leading to incorrect processing taking place.

This becomes noticeable the more the audio playback device sample rate deviates from the audio file that is being played. To reproduce the problem, run the sound effects example using a playback device that is set to a higher than typical sample rate e.g. 384KHz and activate any of the processing filters e.g. echo or low/high-pass filters.

This fix changes the processing filters to use the device sample rate instead.

When running the tennis example with my audio device set to 384KHz sample rate I noticed that the first ball bounce sound was not playing. Subsequent ball bounce sounds played.

Through debugging I found out this was due to the allocated audio frame buffer for high sample rate devices being so large that the entirety of the ball bounce samples was not enough to fill it leading to the first play of the sound not outputting any audio. When creating a device, miniaudio allows specifying periodSizeInFrames. This value is used as a hint when allocating the device buffer, it is clamped between a minimum and maximum buffer size supported by the device. This value is also used as the size of the buffer used to pull audio data through the miniaudio node graph.

In order to prevent the entirety of a sound's samples not filling up the buffer used to pull audio, we simply reduce the size of the buffer used to pull audio data. The smaller the buffer the more frequent miniaudio has to pull audio data since each buffer will contain a smaller duration of data which means that CPU load increases, thus we don't want to set the value lower than it has to be. From testing it seems like setting periodSizeInFrames to 64 allows us to play very short audio clips even on high sample rate devices without the first plays of the audio going missing. If it turns out this value has to be adjusted in the future or a possibility has to be provided for the user to set it through the public API the discussion can continue in another issue.