[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