Modartt user forum - CPU power and latency

Re: CPU power and latency

null@example.com (groovy) — Fri, 27 Feb 2015 21:00:41 +0000

Hi snowjoke,

snowjoke wrote:

groovy - thanks for posting your interesting findings. 16 ms seems like a large difference but I suspect it's mainly due to the time taken for the key to move.

don't know, but I did a little crazy experiment 8-) that stops the time (of the key-move?):

The idea was to press the button of my Korg nanoKONTROL and to move the key of my Kawai at the "same" time (thank you, wine-cork ;-)

The time-difference between the Controller 41 event of the button and the Note On event of the Kawai was around 19 ms and thus in the same league of the ~16 ms latency I estimated in my previous post. A "measured" example in Pianoteq's MIDI log:

It seems, that nearly the half of my overall-latency results from the keyboard. And has nothing to do with the CPU Power of the laptop.

cheers

Re: CPU power and latency

null@example.com (varpa) — Fri, 27 Feb 2015 17:11:25 +0000

I mis-spoke. Lowering the latency will increase the DSP load. DSP is the fraction of CPU time used for audio processing in one audio buffer read cycle. If you reduce the latency there is less CPU time available for audio processing during read cycles are the DSP will approach 100% If it reaches 100% you will like hear audio glitches.

Re: CPU power and latency

null@example.com (snowjoke) — Fri, 27 Feb 2015 01:41:31 +0000

groovy - thanks for posting your interesting findings. 16 ms seems like a large difference but I suspect it's mainly due to the time taken for the key to move. Maybe I will do my own experiment to see if I get similar results (using Windows).

varpa wrote:

Latency is due to several factors and mostly does not depend you your CPU. The nominal latency is due to the configuration of you audio system (in Jack) which is given by (frames/period)*(Periods/buffer)/(sample rate) - using terminology of QJackCtl (since I notice you are using linux). Frames/period is what you call "samples". There can be additional latency due the audio hardware itself. Anyway, latency is determined primarily by the settings you use according to the above formula. The CPU (and audio card) affect how low of a latency you can use before the hardware cannot keep up and you miss audio buffers reads (called xruns) which result in audible glitches. For live play you'll want to keep the latency to below roughly 10 msec to avoid a noticable delay between playing a note and hearing it. For sequencing/mixxing you can set the latency high to give more processing power for your sequencer. The DSP usage is the fraction of CPU time available used when processing audio frames (audio buffers reads). If it reaches 100% you will likely get xruns. Increasing latency will reduce the CPU load. If your computer does frequency scaling, make sure to set it to "performance" to reduce your DSP load.
A SSD will have (almost) no effect on Pianoteq. Well, Pianoteq would start up slightly faster. A SSD is useful if you are playing sampled pianos.

varpa - thanks for your on-topic reply! So, buying a faster computer won't improve my latency, if my current machine can cope with the lowest buffer settings already.

When you say "Increasing latency will reduce the CPU load", do you mean that processing of particularly intense moments can be spread out, hence peak load will be lower? The CPU needs to do the same amount of work whatever the latency, and you already said that latency doesn't depend on CPU power.

Re: CPU power and latency

null@example.com (Beerhunter) — Wed, 25 Feb 2015 16:19:23 +0000

thanks varpa you just gave me the right direction where to fix the problem, just needed to install kernel-tools from the link below.

http://rpm.pbone.net/index.php3/stat/4/...4.rpm.html

Now everything works way better, and i am pretty happy Thank you, made my day !

Re: CPU power and latency

null@example.com (varpa) — Wed, 25 Feb 2015 03:06:54 +0000

There are command line utilities to control CPU like cpufreq. Probably there are an applet you can use in gnome3. Google is your friend.

Re: CPU power and latency

null@example.com (Beerhunter) — Tue, 24 Feb 2015 21:01:25 +0000

@ Varpa do you have any idea how to scale the CPU frequency under gnome 3 ? Fedora 20 with gnome 3 is the OS...

@ groovy, as far as i know you´re right

thank you

Re: CPU power and latency

null@example.com (groovy) — Tue, 24 Feb 2015 14:10:37 +0000

varpa wrote:

Latency is due to several factors and mostly does not depend you your CPU. The nominal latency is due to the configuration of you audio system (in Jack) which is given by (frames/period)*(Periods/buffer)/(sample rate) - using terminology of QJackCtl (since I notice you are using linux). Frames/period is what you call "samples". There can be additional latency due the audio hardware itself.

Assuming JACK audio server daemon is running with these options:

'jackd -dalsa -p128 -n3 -r44100'

(frames/period)*(Periods/buffer)/(sample rate)

128 * 3 / 44100/s = 8.7 ms

Is the calculated "latency" of 8.7 ms correct then?

Is it the latency between the modelled tone and its entry into the audio-hardware? In other words, is 8.7 ms the time spent in JACK audio server until a sample from pianoteq reaches the audio card?

Thanks

Re: CPU power and latency

null@example.com (varpa) — Mon, 23 Feb 2015 20:53:43 +0000

Latency is due to several factors and mostly does not depend you your CPU. The nominal latency is due to the configuration of you audio system (in Jack) which is given by (frames/period)*(Periods/buffer)/(sample rate) - using terminology of QJackCtl (since I notice you are using linux). Frames/period is what you call "samples". There can be additional latency due the audio hardware itself. Anyway, latency is determined primarily by the settings you use according to the above formula. The CPU (and audio card) affect how low of a latency you can use before the hardware cannot keep up and you miss audio buffers reads (called xruns) which result in audible glitches. For live play you'll want to keep the latency to below roughly 10 msec to avoid a noticable delay between playing a note and hearing it. For sequencing/mixxing you can set the latency high to give more processing power for your sequencer. The DSP usage is the fraction of CPU time available used when processing audio frames (audio buffers reads). If it reaches 100% you will likely get xruns. Increasing latency will reduce the CPU load. If your computer does frequency scaling, make sure to set it to "performance" to reduce your DSP load.

A SSD will have (almost) no effect on Pianoteq. Well, Pianoteq would start up slightly faster. A SSD is useful if you are playing sampled pianos.

Re: CPU power and latency

null@example.com (Luc Henrion) — Mon, 23 Feb 2015 19:02:33 +0000

AFAIK, an SSD would not have any influence with PianoTeq: everything is done in RAM.

Re: CPU power and latency

null@example.com (Beerhunter) — Mon, 23 Feb 2015 18:13:57 +0000

Hi guys, i was just wondering if anyone of you could tell me how high the DSP load is while you´re using Pianoteq v5 ?

I got about 25-50% on my maschine, which is the Xeon 1230v3 @ 3.3ghz,8GB of RAM, on an HDD using low latency kernel on fedora 20 with an Focusrite 18i20 USB.

The overall latency of Jack is set to 256 samples so 11.6ms. any suggestions to lower the CPU usage ?
Bitwig Studio is the host.

Would you recommend using an SSD instead of the HDD ?

Thanks

Re: CPU power and latency

null@example.com (groovy) — Wed, 18 Feb 2015 23:13:16 +0000

The remaining unknown variables are the latency for processing a tone and the MIDI-signalling via USB from my Kawai to the subnotebook (Celeron N2930).

I have an estimation for the "unknown variables" eventually. I don't know, how to measure it exactly, but I compared the note-on-latency of my USB-keyboard with the fastest midi-keyboard I have: the virtual-keyboard inside pianoteq clicked with an USB-mouse!

From the noise of the mouseclick to the sound from the speaker I measured ~19 ms (average of five clicks). Example:

And then I repeated the same with my Kawai ES3 connected to the subnotebook with an USB-cable. The average response from 5 hits (forte) was ~35 ms. Example:

So triggering a midi note-on from my USB-keyboard lasts ~16 ms longer than triggering a note from the virtual-keyboard with my USB-mouse (on my system).

EDIT: Assumed that my overall latency is ~35 ms and ~19 ms is the best overall latency I can achieve with the virtual-keyboard, then ~16 ms are needed just to produce the midi-on-event in pianoteq with my real USB-keyboard.

Why is the virtual keyboard ~16 ms faster? Using the real keyboard the (USB) midi-signal has to pass the snd_usb_audio kernelmodule ("driver") on the notebook. Plus the mouse button has a shorter contact-distance than a key. Plus unknown initial latency for midi-note-processing inside the Kawai.

The only parameter that could be influenced is the performance of the snd_usb_audio "driver". With older 2.6x-linuxkernels there was an option 'nrpacks' for example, that could be reduced from 8 to 1, and this shorter chunks improved USB-latency. In newer kernels, like my 3.16x from this experiment, nrpacks is obsolete now and handled automatically AFAIK. BTW, does someone know, if USB-latency can be tweaked somehow nowadays in 3.x-kernels?

cheers

PS: Keep in mind, that the overall latency of course is influenced by the speed of the keypress. Hitting my test-key with ff I saw latencies down to 30 ms (rather than ~35 ms)

Re: CPU power and latency

null@example.com (groovy) — Wed, 11 Feb 2015 07:21:35 +0000

galuwen wrote:

I also tested this and found out that with latest release of ASIO4all you can get a latency of around 10-12ms. The only Thing > my System is new and "clean" :-).
Alexander

Hi,

hm, I suspect this a little, because I have not seen such al low latency in the forum with that microphone-test before. I used Pianoteq 5.1.4, D4 (daily practise), no effects, the 3rd upper c-note on an 88-keyboard. - You do not mean "10-12 ms" in PTQ's preferences, right?

Re: CPU power and latency

null@example.com (groovy) — Wed, 11 Feb 2015 07:11:16 +0000

snowjoke wrote:

Thanks for your reply, groovy. Could you by any chance repeat the test using your Kawai's internal sounds, to compare?

Hello snowjoke,

I tested it a long time ago and got 22 ms from a Kawai ES3 alone, see:

http://www.forum-pianoteq.com/viewtopic...8593#p8593

Re: CPU power and latency

null@example.com (galuwen) — Tue, 10 Feb 2015 23:11:05 +0000

Compared with my CA95 I can state that in the higher range you can hear a "delay", but playing a short period of time you get used to the little delay in my opinion.

I have to Point out, that with my Core i7 machine and Asio4all I can't hear any delay and can Combine both sounds to one suberb "mix Sound".

Alexander

Re: CPU power and latency

null@example.com (snowjoke) — Tue, 10 Feb 2015 23:04:44 +0000

Thanks for your reply, groovy. Could you by any chance repeat the test using your Kawai's internal sounds, to compare?