[LAU] Advice needed: hardware vendors

Len Ovens len at ovenwerks.net
Wed Apr 9 21:47:53 UTC 2014


On Wed, 9 Apr 2014, Luke Hart wrote:

>> That is correct too. Those who run portable applications on a lap top are 
>> the most likely to run into this. The hardware is just not designed to run 
>> full out all the time. The lap top is also more sensitive to dust for this 
>> reason. A desktop machine needs to be kept clean as well.
> Just because the CPU is running at full speed doesn't mean it is generating 
> the maximum amount of heat. If there's nothing for the processor to do (no 
> user task or housekeeping) linux will execute the HLT instruction that puts 
> the processor to sleep until the next interrupt. So heat may not be an issue 
> unless you are running lots of audio processing.

Yup. I have not had this problem myself, but I generally record audio only 
with no soft synths. My low cpu usage should be obvious when I can get 
good low latency on an atom netbook running half speed at 800Mhz  :) But I 
have run at full speed for long periods of time with no problem too.

> Of course the i[357] 
> processors will change the clock speed in response to a wider range of 
> factors, including workload, no. of active cores, current and power 
> consumption (Turbo boost, 
> http://www.intel.com/content/www/us/en/architecture-and-technology/turbo-boost/turbo-boost-technology.html).

That action appears to be switchable. The page says the speed will only 
over clock if the OS asks for more than the non-boosted speed. Some of 
intel's MB will let you turn off the speed switching for heat too (the 
xeon server boards) but you void the warranty  :)  Having a flexable Bios 
is helpful. Using this kind of boost technology is probably not what we 
want for audio processing. Speed changes are very fast and should not be 
noticed by the OS or affect latency (even ondemand should be ok) yet I and 
others have noticed xruns that go away on a solid speed even if that speed 
is slower. Fast CPUs do not mean good low latency. in fact there seems to 
be a move away from known latency towards greatest throughput at any cost. 
Often part of that cost is in latency bumps. There are some low latency 
technologies out there, but they are not geared towards audio, but rather 
stock market servers and therefore network access.

Looking at the intel low latency products (xeon e5 and e7) there are some 
things that look useful to the audio world if there is an audio interface 
that can make use of it. For example the ability to take incoming data 
directly to the cpu cache rather than to system memory first. Boost speed 
is still used in this low latency environment too... This leads me to 
wonder if the xrun at speed switch is not something that could be fixed 
with a better audio (or other) driver.

--
Len Ovens
www.ovenwerks.net




More information about the Linux-audio-user mailing list