Hi,
I’ve been developing an android game with SDL2, and after adding all the sfx I noticed that there is a noticeable delay between the sound’s “deployment” and when the sound is actually played.
Now, I know android is bad with audio latency in general, but I’m experiencing a delay of at least 100+ms, and many other games on android don’t have this problem at all(I personally can’t hear latencies in most of the games I play).
I believe it’s fair to mention that I’m developing in python, but as far as I’m aware SDL is simply compiled with the android NDK and hooked by pysdl, so I don’t really think it matters.
I tried every possible combination of chunk size/frequency available for Mix_OpenAudio. I believe I got small improvements, but the latency is still pretty sensible.
More information about my code:
I load the chunks using Mix_LoadWAV (they’re ogg vorbis, but the decoding should be done a load time, right?)
The chunks are played with Mix_PlayChannel(-1, chunk, 0).
I’ve got exactly the same problem. I’ve tried different chunk sizes and frequencies and the AndroidManifest.xml uses-features tip, but the delay is always shockingly bad. I currently use:
Mix_OpenAudio(44100, MIX_DEFAULT_FORMAT, 2, 2048
and I’ve resampled all my WAV files to be 44100 and cut out any leading or trailing silence on them. Nothing sees to work. I’m just hoping on modern devices it isn’t so awful as the two emulators I try it out on, or the old Huawei device I have for testing on.
Does it affect SDL_mixer or, does it also exist with SDL audio API ?
There are two android audio back-end in SDL: some java API and openslES.
Maybe you can test both individually:
( src/audio/SDL_audio.c: comment out openslES_bootstrap or ANDROIDAUDIO_bootstrap)
try to increase the thread priority of android :
it’s set to “android.os.Process.THREAD_PRIORITY_AUDIO” in SDLAudioManager.java
you can change it to: THREAD_PRIORITY_URGENT_AUDIO
( https://developer.android.com/reference/android/os/Process )
Check the feature of your device:
getPackageManager().hasSystemFeature(PackageManager.FEATURE_AUDIO_LOW_LATENCY);
getPackageManager().hasSystemFeature(PackageManager.FEATURE_AUDIO_PRO);
Hi,
Thank you all for your answers. I have to say I didn’t know about the low-latency feature. I will try that as soon as possible, even if I have to work out how(the python build system I’m using has incomplete documentation and manually updating the manifest isn’t really a thing). I remember trying with the SDL audio api and having similar results, but testing it once more won’t hurt for sure.
About the thread priority, I had absolutely no clue this possibility existed. I’m not really sure where this SDLAudioManager.java should be, but I can investigate(I suppose it’s shipped with the SDL sources?).
Also, I’ve been investigating about audio backends but I couldn’t work it out, thank you for pinpointing the correct sources. A noob question now: is SDL_Mixer based on SDL audio api? Or better, should I expect this changes on the SDL audio api(e.g. backends) to reflect on SDL_Mixer as well?
Sorry about having so many question and so few answers, but I don’t think I’ll have spare time to test everything out for the next few days. I’ll update you on any improvements though(and on any failures).