[SDL] Audio callback function is not called in time sometimes

David Olofson david at olofson.net
Tue Dec 4 12:29:33 PST 2007


On Tuesday 04 December 2007, Mine wrote:
[...]
> I did further investigation, it looks like SDL_Cond_Wait/Signal
> takes the most extra time, and SDL_Lock/Unlock_Mutex takes less
> extra time when the problem occurs. I now use a while loop &
> SDL_Lock/Unlock_Mutext instead of SDL_Cond_Wait/Signal, then it
> works better, there's less audio drop.

What are you using these for? You might want to try some lock-free 
solution for passing "commands" to the audio thread, if that's where 
the problem is...


> Is it possible that SDL_Lock/Unlock_Mutex will take about 30~40
> ticks?

Well, not really, but they certainly increase the risk of you being 
blocked, and whenever that happens, there's a quite substantial risk 
of various other threads running for a while before you get the CPU 
back. You're not on a real time OS, after all.

Also note that due to this dynamic priority deal that any normal OS 
will have, using locks or similar to protect data actually gives you 
a sort of priority inversion problem. It doesn't help that the audio 
thread is behaving and given high priority, if it has to wait on a 
lock held by your CPU hog main thread...!

(As opposed to an RTOS, a normal OS doesn't implement priority 
inheritance and similar solutions to this problem, as priorities are 
just considered a way of tweaking the timesharing a little, 
basically. So, you have to work around it one way or another.)


//David Olofson - Programmer, Composer, Open Source Advocate

.-------  http://olofson.net - Games, SDL examples  -------.
|        http://zeespace.net - 2.5D rendering engine       |
|       http://audiality.org - Music/audio engine          |
|     http://eel.olofson.net - Real time scripting         |
'--  http://www.reologica.se - Rheology instrumentation  --'


More information about the SDL mailing list