SDL3: behavior of samples_frames hint #13397
Description
After some tests of the SDL_HINT_AUDIO_DEVICE_SAMPLE_FRAMES (following #13319), here are some issues and remarks.
My tests consist in printing the additional_amout (or len for SDL2) argument of the callback, and the timestamp of the call in µS:
LOGI("=== [%ld] %d", sc_tick_now(), additional_amount);(LOGI is a macro to log at info level, and sc_tick_now() gives the current time in µS)
WASAPI
It seems that SDL_HINT_AUDIO_DEVICE_SAMPLE_FRAMES on SDL3 is ignored on Windows (with the wasapi driver I guess), the callback is always called with additional_amount = 3840: Genymobile/scrcpy#6216 (comment)
Alsa
On SDL3:
$ SDL_AUDIODRIVER=alsa scrcpy --audio-output-buffer=5 # sample_frames = 240
…
INFO: === [187045691326] 1920
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred
INFO: === [187045691616] 1920Then the callback is never called again.
It works correctly with sample_frames = 480 or sample_frames = 960.
On SDL2, it also "worked" with sample_frames = 240 (even if there were underflows):
INFO: === [188422008920] 1920
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred
INFO: === [188422019712] 1920
INFO: === [188422019730] 1920
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred
INFO: === [188422030329] 1920
INFO: === [188422030358] 1920
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred
INFO: === [188422041071] 1920
INFO: === [188422041114] 1920
ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred
INFO: === [188422051781] 1920
…
Pipewire
Both on SDL2 and SDL3, it seems to work because the callback is called with the expected amount of bytes. For example, if we request samples_frames = 240 (i.e. 5 ms of samples), it is correctly called with a buffer of 240 samples… but if we look at the callback timings, we observe that it is called twice in a row every 10ms. So in the end the smaller output buffer is useless:
INFO: === [187911904031] 1920 |
INFO: === [187911904109] 1920 |
INFO: === [187911914879] 1920 | 2 calls in a row every 10ms
INFO: === [187911915004] 1920 |
INFO: === [187911925521] 1920 |
INFO: === [187911925598] 1920 |
INFO: === [187911936186] 1920 |
INFO: === [187911936331] 1920 |
PulseAudio
On SDL3, it is called 3 times in a row with 1920, 1920 then 256 bytes:
INFO: === [188084460603] 1920
INFO: === [188084460689] 1920
INFO: === [188084460725] 256
INFO: === [188084471221] 1920
INFO: === [188084471336] 1920
INFO: === [188084471460] 256
INFO: === [188084481848] 1920
INFO: === [188084482012] 1920
INFO: === [188084482476] 256
On SDL2, it is called only twice with 1920 bytes, but with a third call every 8 calls (which compensate the missing 256 bytes I guess)
INFO: === [187242273097] 1920
INFO: === [187242273251] 1920
INFO: === [187242283658] 1920
INFO: === [187242283798] 1920
INFO: === [187242294401] 1920
INFO: === [187242294506] 1920
INFO: === [187242294578] 1920 <-- additional call
INFO: === [187242305127] 1920
INFO: === [187242305255] 1920
INFO: === [187242315808] 1920
INFO: === [187242315899] 1920
The behavior in SDL3 looks better, but again, like with Pipewire or alsa, reducing the audio buffer to 5ms has no practical impact if the callback is called several times in a row every 10 (or more) milliseconds (even in SDL2).