Re^2: making something happen in real time

It might be faster to find a module to play the sound, instead of running an external process. It takes more time to start up a new process than for your program to do something itself.
The time to start up a new process is short and predictable. My problem is with latency, which is a long and unpredictable time. (I've also had a lot of problems with Audio::Play in the past, one of which is that it doesn't compile on my Debian system, and it's not available as a precompiled Debian package.)

You could try waking up slightly before you actually want to play the sound, then reading the sound into memory, going into a tight loop briefly, or doing something else that will make sure your program is all ready to go by the time it needs to be.
Sure, I'm just trying to find a way to make my program not be a cpu hog.

Comment on Re^2: making something happen in real time

Replies are listed 'Best First'.
Re^3: making something happen in real time by zentara (Cardinal) on Nov 07, 2005 at 13:49 UTC
If latenecy is your problem, you probably want to patch your kernel to be low latency. Go to Con Kolivas kernel patch , and do groups.google searches for discussion about it. It is widely used for people using their computers for audio work. But I also agree with sgifford that your should try to streamline your playing of the audio. I would try to put the audio in a format that you can store in memory and write directly to /dev/dsp, the Audio::DSP module works well. I'm not really a human, but I play one on earth. flash japh	[reply]
Re^4: making something happen in real time by bcrowell2 (Friar) on Nov 08, 2005 at 00:59 UTC
Ah, thanks, I hadn't known about Audio::DSP -- I'll look into that. I know that, e.g., the gtick metronome app avoids this problem without the need for a kernel patch. Maybe I'll take a look at that code, although my C++ is weak.	[reply]