Best way to ensure accurate timing with C

Question

I am a beginning C programmer (though not a beginning programmer) looking to dive into a project to teach myself C. My project is music-based, and because of this I am curious whether there are any 'best practices' per-se, when it comes to timing functions.

Just to clarify, my project is pretty much an attempt to build some barebones music notation/composition software (remember, emphasis on barebones). I was originally thinking about using OSX as my platform, but I want to do it in C, not Obj-C (though I know it would probably be easier...CoreAudio looked like a pretty powerful tool for this kind of stuff). So even though I don't have to build OSX apps in Obj-C, I will probably end up building this on a linux system (probably debian...).

Thanks everyone, for your great answers.

Answer 1

This is pretty system-dependent. What OS are you using?

You can take a look at gettimeofday() for fairly high granularity. It should work ok if you just need to read time once in awhile.

SIGALRM/setitimer can be used to receive an interrupt periodically. Additionally, some systems have higher level libraries for dealing with time.

Answer 2

gettimeofday() is the best for wall clock time. getrusage() is the best for CPU time, although it may not be portable. clock() is more portable for CPU timing, but it may have integer overflow.

Answer 3

There are two accurate methods for timing functions:

1. Single process execution.
2. Timer event handler / callback

Single Process Execution
Most modern computers execute more than one program simultaneously. Actually, they execute pieces of many programs, swapping them out based on priorities and other metrics to look like more than one program is executing at the same time. This overhead effects timing in programs. Either the program gets delayed in reading the time or the OS gets delayed in setting its own time variables.

The solution in this case is to eliminate as many tasks from running. The ideal environment is for best accuracy is to have your program as the sole program running. Some OSes provide API for superuser applications to block all other programs or kill them.

Timer event handling / callback
Since the OS can't be trusted to execute your program with high precision, most OS's will provide Timer APIs. Many of these APIs include the ability to call one of your functions when the timer expires. This is known as a callback function. Other OS's may send a message or generate an event when the timer expires. These fall under the class of timer handlers. The callback process has less overhead than the handlers and thus is more accurate.

Music Hardware

Although you may have your program send music to the speakers, many computers now have separate processors that play music. This frees up the main processor and provides more continuous notes, rather than sounds separated by silent gaps due to platform overhead of your program send the next sounds to the speaker.

A quality music processor has at least these to functions:

1. Start Playing
2. End Music Notification

Start Playing This is the function where you tell the music processor where your data is and the size of the data. The processor will start playing the music.

End Music Notification You provide the processor with a pointer to a function that it will call when the music data has been processed. Nice processors will call the function early so there will be no gaps in the sounds while reloading.

All of this is platform dependent and may not be standard across platforms.

Hope this helps.

Answer 4

This is quite a vast area, and, depending on exactly what you want to do, potentially very difficult.

You don't give much away by saying your project is "music based".

• Is it a musical score typesetting program?
• Is it processing audio?
• Is it filtering MIDI data?
• Is it sequencing MIDI data?
• Is it generating audio from MIDI data
• Does it only perform playback?
• Does it need to operate in a real time environment?

Your question though hints at real time operation, so in that case...

The general rule when working in a real time environment is don't do anything which may block the real time thread. This includes:

• Calling free/malloc/calloc/etc (dynamic memory allocation/deallocation).
• File I/O.any
• Use of spinlocks/semaphores/mutexes upon threads.
• Calls to GUI code.
• Calls to printf.

Bearing these considerations in mind for a real time music application, you're going to have to learn how to do multi-threading in C and how to pass data from the UI/GUI thread to the real time thread WITHOUT breaking ANY of the above restrictions.

For an open source real time audio (and MIDI) (routing) server take a look at http://jackaudio.org