On 08/05/2012 10:04 PM, Ralf Mardorf wrote: > On Sun, 2012-08-05 at 21:39 +0200, Jeremy Jongepier wrote: >> Just added this to the LinuxMusicians Wiki: >> http://wiki.linuxmusicians.com/doku.php?id=system_configuration#cpu_frequency_scaling > > "The command in your /etc/rc.local file only works if you > disable the ondemand service. On Debian systems: > > sudo update-rc.d ondemand disable > > Another option would be to modify the ondemand init script and > rename it to performance: > > sudo sed -i 's/ondemand/performance/g' /etc/init.d/ondemand > sudo update-rc.d ondemand disable > sudo cp /etc/init.d/ondemand /etc/init.d/performance > sudo update-rc.d performance enable" > > Last time I used Debian there was a script /etc/init.d/cpufrequtils that > set up the governor to ondemand. It's not that long ago, so I guess for > Debian this didn't change. Len of course refers to Ubuntu (Studio). > AV Linux (Debian) also has got /etc/init.d/cpufrequtils: > > "[snip] > # Set ENABLE to "true" to let the script run at boot time. > # > # eg: ENABLE="true" > # GOVERNOR="ondemand" > # MAX_SPEED=1000 > # MIN_SPEED=500 > > ENABLE="true" > GOVERNOR="performance" > MAX_SPEED="0" > MIN_SPEED="0" > [snip]" > > I once wrote a script to toggle between ondemand and performance, not > only for the session, but also to keep it for next startup, based > on /etc/init.d/cpufrequtils. > > Regards, > Ralf > I really wonder why you are all raving about this. Well, it is hard to generalize but on most modern CPUs + main-boards CPU frequency scaling is _not_ correlated to audio-dropouts [anymore] and a non-issue. The time it takes to change CPU frequencies is very small compared (us) to [even] low-latency audio (ms). Concerning Hardware, these days, bus-power-management is most often the cause of xruns on idle systems followed by SMI. Disable PCI and/or PCIe power-management in the BIOS and also disable EIST and C1E halt-states; and, the 'ondemand' governor will works just fine. If you have an unlimited supply of power and noise of cooling the system is of no concern: sure, use the 'performance' CPU-freq governor -- reducing the number of possibilities in complex systems usually increases reliability... which is indeed a good thing for audio. ciao, robin NB. frequency scaling _can_ be an issue when using jack2 (or tschak) on a multi-core machine: The total system-load (over all CPUs) may still be too low for the CPU governor to react, while DSP load is already at the limit. -- http://rg42.org/oss/jackfreqd/ _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
