You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm having some audio issues in my SDL3 project on Android (13) and Windows (11):
There's a significant delay between my call to SDL_PutAudioStreamData and what's actually output to the speakers (up to ~500 ms sometimes). That's about 24000 samples of delay, as I'm feeding 48 kHz input, and that amount of samples doesn't seem to be a common buffer size.
I observed that by blinking an image on the rendering thread, which is vsynced and runs at 144 fps in my computer display (6.94 ms of frame period) and 120 fps in my phone display (8.33 ms of frame period), at pratically the same time I call SDL_PutAudioStreamData, and the delay seems constant. Then I tried delaying the blinking by 500 ms and it seemed more in sync with the audio.
The problem is more serious on Android than Windows, on the other hand, I tried the same code (without the delay compensation on the rendering thread) on Linux (Pop!_OS 22.04) and this issue doesn't happen, or at least I have way less of an audio delay that I could notice.
Calling SDL_FlushAudioStream after SDL_PutAudioStreamData didn't resolve the issue, and is actually undesirable since I want to ensure the timing between the samples I play with sample precision (by padding with silence when necessary), and by calling SDL_FlushAudioStream with its auto-padding:
there may be audio gaps in the output
Is there a way to shorten the delay between the time I feed samples to the SDL_AUDIO_DEVICE_DEFAULT_PLAYBACK and the actual time it outputs to be unnoticeable, by calling SDL_PutAudioStreamData or maybe by doing something else different? (Maybe set the buffer size?)
If not, can I at least query what that delay is for the current system? (query the buffer size? will it matter in AudioStream interface?)
I tried to put up a minimal example that's also easy to verify. It's an aplication that outputs a tic (orange) tac (blue) sound while blinking the screen with the respective color, it has 3 modes: 1, 0.5 and 0.1 second period between sounds that you can switch between by clicking/touching the screen:
Observe that when we get near a 500 ms delay, the tic and tac swap colors on the second interval mode (tic misses the orarnge blink and plays on blue, and vice versa).
Sometimes the delay is not as huge as 500 ms, but you can still verify it by closing you eyes and opening when you hear the tic/tac sound (yes, my application requires that precision in synchronization between audio and video). On Linux, where the delay is imperceptible, you can easly still see the color on the screen, while on Android/Windows most of the time you'll face the black screen.
The text was updated successfully, but these errors were encountered:
Calling SDL_FlushAudioStream after SDL_PutAudioStreamData didn't resolve the issue,
To be clear: this doesn't move data to the hardware, it just tells SDL not to hold data back for correct resampling, because there won't be more data coming to resample against. In terms of an ongoing stream of audio, you never call SDL_FlushAudioStream, you just keep adding more data as appropriate.
So the issue for my main application on Windows was due to other parts of the code (that's why the delay was there but not so significant), now that I tested the minimal example on Windows I get expected results.
But the delay problem still remains on my Android phone, either on my fixed main application as well as in this minimal example I gave.
WIN_20250117_23_25_01_Pro.mp4
NicolasFirmo
changed the title
Significant audio delay between call to SDL_PutAudioStreamData and the actual output (Windows and Android)
Significant audio delay between call to SDL_PutAudioStreamData and the actual output (Android)
Jan 18, 2025
I'm having some audio issues in my SDL3 project on Android (13) and Windows (11):
There's a significant delay between my call to
SDL_PutAudioStreamData
and what's actually output to the speakers (up to ~500 ms sometimes). That's about 24000 samples of delay, as I'm feeding 48 kHz input, and that amount of samples doesn't seem to be a common buffer size.I observed that by blinking an image on the rendering thread, which is vsynced and runs at 144 fps in my computer display (6.94 ms of frame period) and 120 fps in my phone display (8.33 ms of frame period), at pratically the same time I call
SDL_PutAudioStreamData
, and the delay seems constant. Then I tried delaying the blinking by 500 ms and it seemed more in sync with the audio.The problem is more serious on Android than Windows, on the other hand, I tried the same code (without the delay compensation on the rendering thread) on Linux (Pop!_OS 22.04) and this issue doesn't happen, or at least I have way less of an audio delay that I could notice.
Calling
SDL_FlushAudioStream
afterSDL_PutAudioStreamData
didn't resolve the issue, and is actually undesirable since I want to ensure the timing between the samples I play with sample precision (by padding with silence when necessary), and by callingSDL_FlushAudioStream
with its auto-padding:Is there a way to shorten the delay between the time I feed samples to the
SDL_AUDIO_DEVICE_DEFAULT_PLAYBACK
and the actual time it outputs to be unnoticeable, by callingSDL_PutAudioStreamData
or maybe by doing something else different? (Maybe set the buffer size?)If not, can I at least query what that delay is for the current system? (query the buffer size? will it matter in AudioStream interface?)
I tried to put up a minimal example that's also easy to verify. It's an aplication that outputs a tic (orange) tac (blue) sound while blinking the screen with the respective color, it has 3 modes: 1, 0.5 and 0.1 second period between sounds that you can switch between by clicking/touching the screen:
Observe that when we get near a 500 ms delay, the tic and tac swap colors on the second interval mode (tic misses the orarnge blink and plays on blue, and vice versa).
Sometimes the delay is not as huge as 500 ms, but you can still verify it by closing you eyes and opening when you hear the tic/tac sound (yes, my application requires that precision in synchronization between audio and video). On Linux, where the delay is imperceptible, you can easly still see the color on the screen, while on Android/Windows most of the time you'll face the black screen.
The text was updated successfully, but these errors were encountered: