So. I've got a program that I've been working on which uses the Multimedia timer in Windows and would like to port it to linux. The program is used to playback MIDI and other very time sensitive events. The way I had it set-up before, the timer was set to check a queue every ms for messages that needed to be sent that ms. At a high level, what I really need is the ability to efficiently do something like this: Does anybody know how this can be accomplished without polling the timer? I can't be wasting CPU cycles. I've got a lot of other processes that need all the CPU time they can get. P.S. I am also looking for a solution that will work on OS X. Thank You Dwiel

SDL provides exactly what you need. Not only that, you can use the exact same code on Windows, Linux, and Mac OS X. That's the thing about portability libraries, they let you write portable code.

You will need to write some glue code for SDL, however, since you need to be able to tell SDL to fire off timer events from the main event loop. Most people (hence most example code you'll find) seem to like polling the timer and interweaving event loop calls and timer poll calls. Trust me: this will lead to bad news and headaches down the road. You want one loop to rule them all and in the darkness bind them.

--smw

Bregma: I checked out the SDL Timers first actually because I already was using the Video and Threads for the exact cross-platform reasons you provided. However, All of the documentation that I found said that the sleep call (and timers in general http://www.libsdl.org/intro.en/usingtimers.html ) were not guaranteed to return at the specified time, at small time intervals (< 10 ms on most machines) will delay for at the very least, one time slice. I vaguely remember verifying this in windows. Is there some way to get around this?

It looks like gettimeofday and usleep are probably the way to go on linux. Does anyone know if they will work for OSX? That combination seem to make porting what I was doing before with the 1ms callback and a priority queue fairly trivial. I found someone else who was limited to about 4ms in linux due to the 250hz system clock thing, but was able to get around it with some extra hacking and by setting the process as scheduled real-time with a high priority.

I'll see how these work out.

Again, Bregma, if you know how to get past the limitations I mentioned earlier, it would definitely make this whole thing a lot easier.

Thanks

Quote:Original post by Dwiel
Again, Bregma, if you know how to get past the limitations I mentioned earlier, it would definitely make this whole thing a lot easier.

No. My use of SDL is limited to what I need in games, and I never need a millisecond-resolution timer. I would consider millisecond resolution to be hard realtime. I have no good experience using Unix for realtime (although I could offer you some bad experience, and I don't want to go there).

The realtime Unix folk these days seem to enjoy using the realtime signals and sigtimedwait() or sigwaitinfo().

On the other hand, much time-sensitive stuff is often imlemented at the driver level and the userspace API just feeds data into buffers. Userspace timing is just too vague in Unix to be reliable at the microlevel.

--smw

I'll check those functions out too.

Thanks

ended up using clock_gettime and clock_nanosleep. I was unable to get past the 4ms barrier although it turns out this was acceptable (so far), so I didn't go through as much as I could have. I did try setting real-time settings both from within the code using sched as well as with the set_rlimits utility. Neither worked. Hopefully it will not become an issue. I noticed that Hydrogen, the drum sampler software, also gives me a warning message saying that it can't find a clock faster than 250hz, so I guess it couldn't figure out how to do it either. (although they do have to make it all generic - I would like to also)