Re: Latency and Linux

Hi All,
I see there's a bit of a bias against on-board sound chips...  And I understand that.  But I am now getting really good results with my ALC 1150 chip setup.

What is the difference between host sample rate and internal sample rate?  I set my chip "default" sample rate to 96K, and set PT to 96K.  But PT still reports the internal sample rate as 48K.  It reports 1.3ms latency.

Have most of you found the Bluethner piano to sound the best?  I'm thinking to purchase that one.

Re: Latency and Linux

gibbyj wrote:

..I see there's a bit of a bias against on-board sound chips...  And I understand that.

I think that the bias is against any sound chip system that carries a high latency, such as what I have with my Windows laptop. If the latency were low with my on board components, I wouldn't bother buying my Presonus Audiobox.

What is the difference between host sample rate and internal sample rate?  I set my chip "default" sample rate to 96K, and set PT to 96K.  But PT still reports the internal sample rate as 48K.  It reports 1.3ms latency.

I'm going to pass on this out of ignorance

Have most of you found the Bluethner piano to sound the best?  I'm thinking to purchase that one.

This will all be a matter of personal opinion. My own bias is towards the Model B Grand closely followed by the Blüthner. But hey, you can try them all out prior to purchasing, so you can easily find what you like best before buying.

Re: Latency and Linux

What is the difference between host sample rate and internal sample rate?  I set my chip "default" sample rate to 96K, and set PT to 96K.  But PT still reports the internal sample rate as 48K.  It reports 1.3ms latency.

I think I can partially answer this now for myself.  I noticed that the "Pro" version of PT allows higher than 48K sampling (up to 192K).  All the other versions are limited to 48K.  I expect this doesn't matter much, practically.  However, when I increased the sample rate from 44 to 48 to 96, the sound seems louder and I don't have to turn up my amp as high, which is good for reducing noise, I think.  Would still like somebody to explain more what "internal" vs. "host" sample rates are.  Thanks!

Last edited by gibbyj (23-05-2016 13:52)

Re: Latency and Linux

gibbyj wrote:

Would still like somebody to explain more what "internal" vs. "host" sample rates are.  Thanks!

The developers would be the best people to answer that. You can contact support and ask; they're a helpful lot...

But as far as I understand "internal" is to do with the modelling engine, the output of the mathematical model: the calculations that produce the sound on the fly. "Host" is what is sent to your sound card driver. So if you have internal < host, the model's output is interpolated to 'up-scale' the sampled "internal" audio signal it calculates. Best to stick with host = internal, or perhaps host = integer x internal, or occasionally host = simple rational number x internal; e.g., host = 3/2 x internal, say 48 kHz = 3/2 x 32 kHz is good but say host/internal = 48/41.1 or 96/41.1 are bad (and the Ptq UI will display a warning to let you know about it). The latter are computationally more intensive and the high-frequency components of the signal will be degraded because 48 or 96 samples do not easily "mesh" with 44.1 samples. It's like when you upscale digital photos: 2x tends to yield a sharper image than say 1.9x or 2.1x.

You may be curious why you might want anything other than Internal = Host (which is typically the best choice). There are various reasons but I don't want to bloat this post much more. When in doubt, experiment and see what works best.

Last edited by SteveLy (23-05-2016 15:23)
3/2 = 5

Re: Latency and Linux

groovy wrote:

PS: My standard-tunings: intel_pstate set to performance; limits.conf; alsa direct to hardware without conversions.


For newer Intel-CPU based computers that use the intel_pstate frequency scaling instead of the older CPU-throttling governors in Linux, you might try disabling the intel_state CPU frequency scaling altogether. I tested my computer/Pianoteq/audio setup with CPU's set to performance (in the BIOS) and then with intel_pstate disabled (in the linux kernel command line in the bootloader, grub) and found I could achieve lower latencies, smaller buffer sizes and fewer number of buffers (periods), and better performance with fewer or no overruns (Xruns) with intel_pstate completely disabled at boot time, to cause all CPU cores to run at the fixed factory-maximum (not overclocked) frequency.

As the root user (using "sudo" or "su root" and the vim editor, or "gksudo gedit /etc/default/grub") I edited the file /etc/default/grub, and changed this line--

GRUB_CMDLINE_LINUX_DEFAULT=""

to this--

GRUB_CMDLINE_LINUX_DEFAULT="intel_pstate=disable"

Then as the root user I ran the command update-grub to cause the change to be written to GRUB's configuration file in /boot, then rebooted the machine.

Last edited by Stephen_Doonan (24-05-2016 14:22)
--
Linux, Pianoteq Pro, Organteq

Re: Latency and Linux

Stephen_Doonan wrote:

I tested my computer/Pianoteq/audio setup with both intel_pstate set to performance (in the BIOS) and then with intel_pstate disabled [..]

"In the BIOS"??
Intel_pstate is a scaling_driver in the linux-kernel for newer Intel CPUs. Once the kernel is booted and the driver is loaded, the scaling_governor has to be set to "performance" (for each cpu core), else just "powersave" is set by default.

Because I have no Xruns or something in my linux-setup, there is no need for me to use the fall-back/backward-compatible scaling_driver acpi-cpufreq and its tools. KISS-principle has its charme

Just for interest, have you found a difference in Pianoteq's performance-index (acpi-cpufreq vs. intel_pstate) using your settings? (whatever those settings were)

Re: Latency and Linux

groovy wrote:

"In the BIOS"??
Intel_pstate is a scaling_driver in the linux-kernel for newer Intel CPUs. Once the kernel is booted and the driver is loaded, the scaling_governor has to be set to "performance" (for each cpu core), else just "powersave" is set by default.


I'm sorry. I should have said that, to begin with, I attempted to address the CPU frequency scaling issue in the (Asus) BIOS of my desktop computer by--

  • setting CPU's to "Performance" mode

  • disabling "Intel SpeedStep"

  • disabling "Intel TurboBoost

However, those BIOS settings had no effect after the linux system booted. The Linux kernel loaded the intel_pstate driver automatically, and I discovered that even manually changing the intel_pstate governor from "powersave" to "performance" after bootup for each of the 6 CPU cores did not disable frequency scaling: the CPUs' frequencies were apparently still being stepped, changed, scaled, by the kernel's intel_pstate driver. I could see this effect in Pianoteq, in the Perf tab of the Options, where the CPU cores are identified and their running frequency (or frequency range) is indicated.

So, for now, the only method I found to disable CPU frequency scaling completely and to cause the CPU cores to all run constantly at a fixed frequency has been to disable the kernel's intel_pstate CPU-frequency-scaling driver, by adding "intel_pstate=disable" to the linux kernel commandline at bootup, as I described above.

Sorry for the confusion.

Last edited by Stephen_Doonan (24-05-2016 15:09)
--
Linux, Pianoteq Pro, Organteq

Re: Latency and Linux

Ah, thanks for clarification, no problem at all.

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).

Re: Latency and Linux

To groovy--

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.

Last edited by Stephen_Doonan (25-05-2016 00:24)
--
Linux, Pianoteq Pro, Organteq

Re: Latency and Linux

Stephen_Doonan wrote:

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.

Re: Latency and Linux

Thanks guys for the info. I'm watching and learning. Till now I've just been using cpufrequtils (cpufreq-info and cpufreq-set):

> cat ~/bin/cpumaxspeed 
#!/bin/bash

MAX_FREQ=$(cpufreq-info | grep limits | head -n1 | cut -f2 -d- | sed 's/ //g')
ICPU_MAX=$(cpufreq-info | grep analyz | tail -n1 | cut -f 3 -d' ' | cut -f1 -d:)

for ((i = 0; i <= $ICPU_MAX; i++)); do
        sudo cpufreq-set -c $i -f $MAX_FREQ
done
Last edited by SteveLy (25-05-2016 09:33)
3/2 = 5

Re: Latency and Linux

groovy wrote:

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

Last edited by Stephen_Doonan (25-05-2016 15:29)
--
Linux, Pianoteq Pro, Organteq

Re: Latency and Linux

Stephen_Doonan wrote:

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

Re: Latency and Linux

groovy wrote:

... 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

Last edited by Stephen_Doonan (25-05-2016 19:08)
--
Linux, Pianoteq Pro, Organteq

Re: Latency and Linux

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

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
acpi-cpufreq

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
2400000 2000000 1800000 1600000 1400000 1200000 1000000 800000

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
1000000

# cpufreq-set -f 1200000

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
1200000

Re: Latency and Linux

Why are people often so obsessed with minimizing Latency? My experience is everything below 5 ms or even 10 ms is usable. This should be no problem on modern hardware on any OS.

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.

Re: Latency and Linux

m.tarenskeen wrote:

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--

Last edited by Stephen_Doonan (25-05-2016 22:51)
--
Linux, Pianoteq Pro, Organteq

Re: Latency and Linux

groovy wrote:

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.

Last edited by Stephen_Doonan (25-05-2016 22:39)
--
Linux, Pianoteq Pro, Organteq

Re: Latency and Linux

Stephen_Doonan wrote:

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. 

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?

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.

Re: Latency and Linux

groovy wrote:

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.

--
Linux, Pianoteq Pro, Organteq

Re: Latency and Linux

Stephen_Doonan wrote:
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.

Re: Latency and Linux

alessandro wrote:

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.