As far as I understand there is no ring buffer (like DirectSound) and I can queue multiple buffers calling SDL_QueueAudio.
So, what is the meaning of the field SDL_AudioSpec.samples?
It does make a difference so, it is being used.
Related question: from the moment a call to SDL_QueueAudio is made, how long is the queue for that data to be played? SDL_GetQueuedAudioSize can be used, but I cant understand its link to SDL_AudioSpec.samples.
I am using SDL 2.26.3, on Ubuntu 23.04, audio driver = pulseaudio.
https://wiki.libsdl.org/SDL2/SDL_QueueAudio
SDL offers two ways to feed audio to the device: you can either supply a callback that SDL triggers with some frequency to obtain more audio (pull method), or you can supply no callback, and then SDL will expect you to supply data at regular intervals (push method) with this function.
When using a callback function you’ll get a pointer to a buffer as argument. The job of the callback is then to fill the buffer with audio samples. The size of this buffer is what SDL_AudioSpec.samples refers to. Using a smaller buffer size will reduce the latency (delay before the sound plays) but going too low could cause problems if it’s not able to keep up the pace.
I don’t know exactly how SDL_QueueAudio works but I suspect it just uses its own callback with the same buffer size.
I have been using SDL_QueueAudio but I wonder if the other way would give me more control.
Anyway, if I understand this correctly, from the moment I queue something, it will need to wait for everything already queued on the SDL side + finally go via the SDL_AudioSpec.samples buffer.
Otherwise, with the callback, the is no SDL queue (but probably some circular buffer on my side), but the “path to hardware” is easier to understand.
Are there some examples when one method is better than the other?