I’ve got a question regarding the audio API, and how the samples parameter of the SDL_AudioSpec structure is used.
When I worked on a patch I submitted a while back for the ALSA backend (https://bugzilla.libsdl.org/show_bug.cgi?id=4156) it seemed that most audio backends used the samples parameter to mean frames, and they often try to create an audio buffer that’s 2x the requested frames parameter.
So, if samples was 256 and the frame size was 4, it’d attempt to create a total buffer of 256 * 4 * 2 bytes and if the hardware was capable, the obtained spec returned by SDL_OpenAudioDevice would contain samples = 256 frames, while the buffer itself is actually 512 frames.
In effect, the returned samples parameter is equal to the period size, and the number of periods can be assumed to be approximately 2 (but it’s not guaranteed). The problem being, it’s not possible to understand the total buffer size / audio latency without knowing both of these values.
Would it make sense to modify the API to report both the period size and number of periods?