On Wed, 9 Apr 2014, Luke Hart wrote:
>> That is correct too. Those who run portable applications on a lap top are
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
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.
Linux-audio-user mailing list