People doing real-time audio processing on Linux are generally very picky about details (real-time kernel with full preemption, fine-tuning or the IRQ priorities, ...). However I did not cross any document mentioning possible drawbacks of CPU frequency throttling. This feature is now available everywhere. Even my quad-core tower spends most of its time at 1.6GHz instead of 2.66GHz. My good old D800 laptop runs at 600MHz when it is idle, and jumps to 1.6GHz when it needs to. But the question is how fast does it transition from 600MHz to 1.6GHz ? This small program does measure it, using the TSC counter. Please note that this does not work on recent CPU as the TSC rate is no more equivalent to the processor speed (that is its rate is now constant).

And finally the result: on my single-core pentium-m, the max cpu frequency is reached after ~0.05 - 0.1 seconds on a desktop kernel (2.6.27) , and 25 ms on the "linux-rt" kernel . Definitively not a negligible latency. That means that if your audio processing load is not smooth, and you have bursts of cpu usage (for example when new notes are played on your great but cpu-hungry softsynth), then you will not be able to use 100% of your cpu, but only 600/1600*100 = 37.5% of its power ! Not great.

But maybe using threads with real-time (SCHED_RR) priority will help ? Just run the program with "-rt" argument. Now the latency is 1 full fucking second on the "normal" kernel, and +INF seconds on the linux-rt kernel !! Not great at all. Of course, cpufreq being a deamon, it has much less chances to get scheduled where a very high priority thread is consuming all cpu. Ok, that is not fair, so you can add a small usleep(10) in the main loop in order to leave it a chance to do its job (the "pthread_yield" is not enough, apparently). And then the latency is back to ~0.1sec on desktop kernel , but still >10sec on rt kernel.

As a conclusion, I would say that doing a 'cpufreq-set -g performance' when your audio software is running is certainly not a stupid idea. Especially on a single-core cpu where the cpufreq deamon is likely to be starved when things start to get hot.