Running Pianoteq on an i5, you'll probably have the same latency in Windows and in Linux. No need to change.

If you really like computers, though, I think that exploring different operating systems is something that will enrich your knowledge a lot. Start with a popular distribution (any Ubuntu variant), test an audio-specific distro (e.g. KXStudio, AVLinux), dive deep with Arch... Then explore the alternatives: build a Hackintosh, discover Haiku, run the fastest android with Android-X86... OK, I'm going too off-topic. ;-)

No new question here really, just an FYI:  I'm getting back to this after a long time using Pianoteq with good success on Windows 10 i5 3ghz, buffer size 64, low latency, performance index 50 or 60.  But now I'm playing with my speakers; integrating large woofers in larger sealed cabinets, to get the low notes to sound better.  Want to try DSP to equalize and integrate the woofer response (12" SB Acoustics drivers with 19hz fs).  I hope to get reasonable response in the 20-30hz range (for the lowest note and for harmonics below it).  I have Pianoteq Pro now and isn't it correct that I can also edit the notes individually to boost the lowest ones, as part of equalization?  Am now trying AVLinux and I found an interesting approach with "ecasound" Linux package (and add-ons by a guy named Richard Taylor), to do the DSP right on my i5 computer alongside Pianoteq, using Jack to talk between them.  New SSD arrives today so I can switch from LiveDVD AVLinux to a real installation, and get Pianoteq running.  Am finding good posts here on Linux with lots of details, thanks all.

m.tarenskeen wrote:

Why are people often so obsessed with minimizing Latency? ... xruns can ruin that one and only perfect live recorded take.

At any rate, it seems that a common and important task is the balancing of the competing ideals of low latency and glitch-free performance, depending upon the particular use of the audio tools and one's goals.

Just a personal opinion--

I don't think that's a personal opinion. Finding that balance is something we all have to deal with. It's a fact,  it's how it works: not an opinion.

a good thing in Linux is, that we have the choice, what we prefer in a special situation.

Yes, I love all the options available in Linux.

Thanks for the reply.

Groovy, I believe that the acpi-cpufreq utilities/driver/module are not used and not available by default with CPUs that include intel_pstate functionality. Is this correct?

Newer Intel CPU(s) support  intel_pstate for cpu frequency scaling. Therefore this is the chosen default in the most Linux distros today. But this support can be switched off in the kernel with intel_pstate=disable when passed to the kernel with the bootloader. Then the kernel falls back to the legacy scaling_driver acpi-cpufreq (automatically). This driver acpi-cpufreq can be controlled comfortably with the well-known tools and initscripts in the packet cpufrequtils. 

Normally I'am using my fanless netbook with the Intel N2930 cpu, this is a fairly new cpu and it supports intel_pstate. On older laptops (core2duo and i3) I used the "classical" acpi-cpufreq driver together with RT-kernels (the i3 we saw in my previous post).

It is not so complicated as it all looks like. Just a transition from one scaling driver to another and a good thing in Linux is, that we have the choice, what we prefer in a special situation.

Setting a fixed cpu frequency works with the scaling_driver 'acpi-cpufreq':

Groovy, I believe that the acpi-cpufreq utilities/driver/module are not used and not available by default with CPUs that include intel_pstate functionality. Is this correct? Does your CPU have intel_pstate functionality, or is it a slightly older or different CPU (perhaps for laptop computer use primarily) that does not include the intel_pstate functions?

I probably ought to do some additional research.

Why are people often so obsessed with minimizing Latency? ... xruns can ruin that one and only perfect live recorded take.

I agree that focusing too strongly on minimizing latency can itself become a problem.

However, there are different considerations when one is recording audio, and when one is performing (such as on a musical instrument) and is listening to (monitoring) one's own performance while performing. In the latter case, even latencies as low as 5 milliseconds can be noticed  (compared to even lower latencies), and latencies much higher than that can become somewhat frustrating to the performer, if not to the person recording the performance.

It has often been said that one of the best latency-compensation tools is the accustomed human mind of a person that has learned to play a large, traditional pipe organ, where the time between pressing a key on the organ manual and the sound emitting from the pipe can be quite long (in terms of what one might ideally hope for). In such cases, the organ player must often continue to move their fingers to the next notes even before they hear the results of their previous finger movements and key presses.

At any rate, it seems that a common and important task is the balancing of the competing ideals of low latency and glitch-free performance, depending upon the particular use of the audio tools and one's goals.

Just a personal opinion--

I am more interested in stable and glitch-free performance. On my Linux boxes I have had serious problems in the past with hickups, clicks, distortion, xruns, and even total freezes, until I found good configuration instructions from Linux pro-audio users on the internet.

xruns can ruin that one and only perfect live recorded take.

... I'm not convinced. Have you checked the *real* kernel settings available under /sys/devices/system/cpu/* ?? I'm a bit skeptical

I was skeptical too (I think it's good to be a little skeptical ), and am still a little wary of using the cpufrequtils bootup script in /etc/init.d

So I did check the settings in /sys/devices/system/cpu/* to try to convince myself that the cpufrequtils script, and the cpufreq-info command-line utility, were (or rather, are) giving accurate information.

In my Linux system (LinuxMint 17.3), there are directories for each CPU core located at--

/sys/devices/system/cpu/cpufreq/

The directories inside that location are--

policy0
policy1
policy2
policy3
policy4
policy5

--because my CPU (an Intel i7) has 6 cores, 0-5.

Inside each of those directories (/sys/devices/system/cpu/cpufreq/policy0/ for example) are text files, as follows--

affected_cpus
cpuinfo_cur_freq
cpuinfo_max_freq
cpuinfo_min_freq
cpuinfo_transition_latency
related_cpus
scaling_available_governors
scaling_cur_freq
scaling_driver
scaling_governor
scaling_max_freq
scaling_min_freq
scaling_setspeed

If, in a command-line terminal, inside /sys/devices/system/cpu/cpufreq/cpu0 (or cpu1, cpu2, etc.), I type the command--

sudo cat *

--the cat program prints out the contents of each of those files on a separate line, and in the case of cpu0, this is the output--

0
1580500
3800000
1200000
4294967295
0
performance powersave
1580500
intel_pstate
performance
3600000
2400000
<unsupported>

I'm a bit confused and worried by the last item, the contents of the file scaling_setspeed being <unsupported>, so I plan to do a little research about that. I think it means that using the intel_pstate frequency scaling kernel driver, a particular set and fixed frequency cannot be specified; the governor under the intel_pstate driver will always choose a range and never function at a specified fixed frequency.

Note: the path--
/sys/devices/system/cpu/cpufreq/policy0/
--is identical  to--
/sys/devices/system/cpu/cpu0/cpufreq/
--because "cpufreq" in the path immediately above is a symlink to ../cpufreq/policy0

This is an alternate method (to the script you mentioned earlier in the discussion) of setting the governors for all the CPUs (all the CPU cores).

... I'm not convinced. Have you checked the *real* kernel settings available under /sys/devices/system/cpu/* ?? I'm a bit skeptical, because the cpufrequtils only were effective as expected with the legacy driver acpi-cpufreq in the past (and not with the driver intel_pstate). Maybe the package cpufrequtils was updated in the meantime to support intel_pstate, but I found no indication in the changelog ... hm

I'm using a little script started at boottime from /etc/rc.local. It is called "governor" (thanks to user delt)

If you install the package cpufrequtils, in addition to the command-line (terminal) programs cpufreq-info and cpufreq-set, the cpufrequtils package will install a bootup script in /etc/init.d/ called "cpufrequtils" which uses the cpufreq-info and cpufreq-set command-line utilities installed by the same package to set the governor and operating frequency range for each CPU (each CPU core).

This cpufrequtils script may be edited as root to set both the governor and a suggested frequency range for the governor to use for all the CPU cores, when the script launches automatically during computer bootup.

For example, after the cpufrequtils package is installed, the cpufrequtils file it creates in /etc/init.d (which is symlinked to and run in various runlevel directories such as /etc/rc2.d/) includes the following text--

# 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="ondemand"
MAX_SPEED="0"
MIN_SPEED="0"

I edited the /etc/init.d/cpufrequtils files as root so that the non-comment lines (the ones that have an effect; that don't begin with a # indicating that the line of text is merely a non-functional comment) above read as follows--

ENABLE="true"
GOVERNOR="performance"
MAX_SPEED="3.6GHz"
MIN_SPEED="2.4GHz"

Note-- Because my computer's CPU uses the intel_pstate functionality, the "ondemand" governor mentioned in the cpufrequtils script is not available (the only available governors are "powersave" or "performance"). So I changed the GOVERNOR= to "performance" although I could also have specified "powersave"

And now, at computer bootup or by restarting the cpufrequtils script while the computer is running ( by using a terminal and typing the command: service cpufrequtils restart ), the command-line program cpufreq-info produces the following output for my 6-core Intel i7 CPU--

cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 0.97 ms.
  hardware limits: 1.20 GHz - 3.80 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 2.40 GHz and 3.60 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 1.28 GHz.
analyzing CPU 1:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 0.97 ms.
  hardware limits: 1.20 GHz - 3.80 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 2.40 GHz and 3.60 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 1.58 GHz.
analyzing CPU 2:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 2
  CPUs which need to have their frequency coordinated by software: 2
  maximum transition latency: 0.97 ms.
  hardware limits: 1.20 GHz - 3.80 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 2.40 GHz and 3.60 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 2.23 GHz.
analyzing CPU 3:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 3
  CPUs which need to have their frequency coordinated by software: 3
  maximum transition latency: 0.97 ms.
  hardware limits: 1.20 GHz - 3.80 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 2.40 GHz and 3.60 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 1.52 GHz.
analyzing CPU 4:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 4
  CPUs which need to have their frequency coordinated by software: 4
  maximum transition latency: 0.97 ms.
  hardware limits: 1.20 GHz - 3.80 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 2.40 GHz and 3.60 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 2.30 GHz.
analyzing CPU 5:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 5
  CPUs which need to have their frequency coordinated by software: 5
  maximum transition latency: 0.97 ms.
  hardware limits: 1.20 GHz - 3.80 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 2.40 GHz and 3.60 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 2.03 GHz.

This is an alternate method (to the script you mentioned earlier in the discussion) of setting the governors for all the CPUs (all the CPU cores).

If a person wishes to edit the /etc/init.d/cpufrequtils file (or any other file) as root, but in a graphical editor instead of a command-line editor like vim, there are many graphical editors to use (such as gedit or kate), and many ways to launch the graphical editor with root-user privileges. I use a version of Linux that relies on the GTK+ graphical toolkit (instead of QT), and has the gedit graphical editor installed by default, so the command gksudo opens a small graphical window to type the root password before launching the specified program (the editor), which opens the file I wish to edit, with the command--

gksudo gedit /etc/init.d/cpufrequtils

May I ask how you set the governor for each or all of your CPU cores to "performance" (instead of the default "powersave").

I'm using a little script started at boottime from /etc/rc.local. It is called "governor" (thanks to user delt):

/usr/local/bin/governor performance

This script contains:

#!/bin/sh

cd /sys/devices/system/cpu
gov="$1"

if [ "$gov" = "" ]; then
  for core in cpu?; do
    echo -n "Core ${core} set to "
    cat ${core}/cpufreq/scaling_governor
  done
else
  if [ "`whoami`" != "root" ]; then
    echo "Root access is required for this operation. Trying sudo..."
    exec sudo "$0" "$@"
  fi
  for core in cpu?; do
    echo "Setting core ${core} to ${gov}... "
    echo "$gov" > ${core}/cpufreq/scaling_governor
  done
fi

As far as I know, with the intel_pstate driver *static* cpu frequencies cannot be set any longer (contrary to the former acpi-cpufreq driver). It only has two different  dynamic ranges, called powersave and performance.

My CPU is an Intel i7 six-core CPU with a listed operating frequency of 3.2 GHz. With "Intel Turboboost" enabled in the BIOS (and only with Intel Turboboost enabled), the CPU cores can operate up to a frequency of 3.8 GHz (instead of 3.2 GHz).

With the CPU governor for all six CPU cores set to "performance" instead of "powersave," the CPU cores are allowed to operate within the range of 1.2 GHz to 3.8 GHz. In Pianoteq, the base frequency is listed as 3.2 GHz (the Intel factory standard), while the active CPU frequency ranges fluctuate between a low of  1.2 GHz to a high of about 3.4 GHz, and rarely above, with a CPU load, when multicore rendering is enabled in Pianoteq, to usually no more than 25-35% (and usually less than 25%).

I'll try using Pianoteq in this mode for awhile, with the intel_pstate kernal driver in effect, and the governor set to "performance," and see how the system behaves with regard to overruns (Xruns), MIDI responsiveness, low latency and CPU load.

May I ask how you set the governor for each or all of your CPU cores to "performance" (instead of the default "powersave"). Do you use a commandline utility, or manually type an echo command in a terminal, or edit a configuration file in /etc or /etc/init.d/ ? And do you specify a fixed frequency for the governor, or alter its default frequency range? Thanks.

Indeed it is an interesting point, what are the implications of a fixed/nailed cpu-frequency versus a dynamic frequency scaling in performance mode.

For illustration I take my N2930 which has a base frequency of 1.83 GHz and a burst frequency of 2.16 GHz.

Pianoteq shows in the Perf window the range of the minimum and maximum CPU frequencies of all cores, refreshed every half second (I guess). The maximum is always 2,16 GHz, which means at least one of the four cores is in burst mode. The minimum frequencies are fluctuating, so you are right there is some dynamic scaling even in performance mode of the intel_pstate driver. While playing, the minimum is higher than 1.83 GHz most of the time (but sometimes I see lower freqs like 1.3 or 1.5 GHz just for example).

In the past, when I experimented with the alternative driver acpi-cpufreq (which you are using), I remember I could nail down one of these frequencies:

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 
1827000 1826000 1660000 1494000 1328000 1162000 996000 830000 664000 498000

... in other words I could set a static, max. frequency of 1.83 GHz to each core with acpi-cpufreq. Eventually it is positive for audio to have static circumstances (prediction of the behavior; no potential side-effects from scaling).

But on the other hand, do we loose the burst-modes (2.16 GHz), that the intel_pstate makes heavy use of? at least on my N2930?

Stephen_Doonan,
as you are running the driver acpi-cpufreq -- could you please check, if your CPU is using the burst mode even if you nailed your max. available frequency? (just watch the Perf window of PTQ whether the range goes up to the burst frequency).