High-resolution timing (to start audio sample playback) in lispbuilder-sdl

[stack9...@gmail.com]

Normal SDL event loop is good enough for most human-scale timing events, but the event-loop jitter is giving me problems when starting audio events.

I am working on an asteroids-style game.  In the background, I am playing two alternating 'thump' samples, and as the game picks up the thump come more often.  Unlike graphics, where an occasional timing glitch or jitter is barely noticeable as long as it's corrected for, a sample starting tens of milliseconds late is disturbing, and the usual means of correction make for two out-of step thumps instead of one. 

Is there a mechanism that would allow me to start audio playback of a sample in a more controlled way than hoping that the event loop is close enough?  There was some useful information here: https://code.google.com/p/lispbuilder/wiki/UsingLispbuilderSDL#Introduction_to_Frame_Rate_and_Timestep but my attempts to set constant frame rate, or unlocked framerate with callbacks had little effect on the uneven quality of the thumping.

If you have a few minutes to see what I am talking about, my repo at github is 

https://github.com/stacksmith/asteroids

Has anyone encountered (or hopefully solved) a similar issue? 

[Elliott Slaughter]

I haven't seen this personally, but I had some thoughts:

SDL_GetTicks, which the entire with-events/fps code is based on, returns time at a millisecond granularity. So if you need to do anything more precise than that, you'll need a high(er) resolution timer. But that wouldn't explain the off-by-10s-of-ms issue, except...

SDL_Delay (used in the default FPS manager in Lispbuilder) depends on the OS schedule to wake, which is on many systems works at quanta of about 10ms, and is frequently off by about that much. So that would explain why a normal time loop doesn't do what you want, but not when you use the unlocked framerate...

So I went back and read the code for fps-unlocked in lispbuilder-sdl/sdl/fps.lisp, and then the article that the code links to. And I wonder if that code is really doing what you want, because the goal of that algorithm is to run your physics timestep the correct number of times per graphics timestep, but *not* necessarily to run the physics timestep at regular intervals. So if your graphics timestep takes on the order of 10ms, and the physics takes more like 1ms, then even though most of the time physics will run every ms, there will *still* be 10ms gaps in the timeline when everything is stalled to do graphics. And of course if physics is similarly slow then you run into the same problem in the other direction.

How long do your graphics and physics take? :-)

If the either take ~10ms, then that's probably your issue. In which case you have two options: make them faster, or resort to some sort of multithreading. (Hint: thread is not much fun, so you should probably avoid it if you can.)

If they're both fast, then I'm out of ideas. I guess you just go back to normal performance debugging at that point (which is to say, put timers absolutely everywhere and see where the time is going).

--
You received this message because you are subscribed to the Google Groups "Lispbuilder" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lispbuilder...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Elliott Slaughter

"Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay