https://youtu.be/4QYlIZP8Dl4?si=inPaI8BVITJRFpjq

I know that in my keyboard controller, the delay between the "hammer strike" and the end of receiving a message to the computer via USB is about 30-50 us. The delay before the sound appears is ~4 ms:

If you make the buffer size larger, then ~4 ms is added to the buffer size. This works the same on Windows and Fedora. The same with USB 2 and 3.

The following worries me: with my controller, I increasingly play at low speeds. At the same time, Pianoteq adds a small delay (larger for lower MIDI speeds), which is designed to improve interaction with digital MIDI controller keyboards. To make the sensations a little more realistic when using digital piano keyboards. This works well with VPC1 for example. But with a "live" keyboard (or owners of keyboards like Yamaha N1X and similar) it makes no sense. I remember that I mentioned this point before and such an additional delay was added during updates. This delay becomes noticeable when playing quietly and does not add convenience when using a live keyboard. Now I would ask the developers to add the ability to launch Pianoteq without this delay. Make this delay disabling in the menu. Or disabled with an additional flag when launching from the terminal. (Most often, Pianoteq is launched from a Bash script and this would be convenient). Thank you!

--

I love Linux, MacOs is good and I'm confused by Windows.

dubc wrote:

dikrek wrote:

RT can significantly degrade overall throughput, battery life, and preempt things you may not want preempted.

So if I am running a DAW with lots of plugins, I would test to see which kernel doesn’t impact overall throughput too much yet also allows low latency.

For a general use machine I’d probably just go lowlatency.

Thats really something that I thought had been resolved but you are correct. Ill try towards the end of the week and report back. Thank you!!!

How did it go?

I couldn't get low latency only rt plus low latency.  I'm happy still but check every week to see if low latency is available.

dikrek wrote:

RT can significantly degrade overall throughput, battery life, and preempt things you may not want preempted.

So if I am running a DAW with lots of plugins, I would test to see which kernel doesn’t impact overall throughput too much yet also allows low latency.

For a general use machine I’d probably just go lowlatency.

Thats really something that I thought had been resolved but you are correct. Ill try towards the end of the week and report back. Thank you!!!

How did it go?

dikrek wrote:

RT can significantly degrade overall throughput, battery life, and preempt things you may not want preempted.

So if I am running a DAW with lots of plugins, I would test to see which kernel doesn’t impact overall throughput too much yet also allows low latency.

For a general use machine I’d probably just go lowlatency.

Thats really something that I thought had been resolved but you are correct. Ill try towards the end of the week and report back. Thank you!!!

Lowlatency even allows live patching with Ubuntu Pro. The RT kernel has many restrictions.

https://ubuntu.com/security/livepatch/d...ce/kernels

RT can significantly degrade overall throughput, battery life, and preempt things you may not want preempted.

So if I am running a DAW with lots of plugins, I would test to see which kernel doesn’t impact overall throughput too much yet also allows low latency.

For a general use machine I’d probably just go lowlatency.

Thats really something that I thought had been resolved but you are correct. Ill try towards the end of the week and report back. Thank you!!!

dv wrote:

That is indeed impressive, but how did you measure that? More than the "declared" latency (which includes only what the software declaring it knows about), I think it's important to know actual latency. The only way I know to "scientifically" measure the latter is with a highly accurate high-speed audio-video recording device -- checking the time delay between your pushing down the key(s) and the sound being recorded.
It's very important to keep in mind that the recording device needs to have very tight sync between audio and video, and that the speed of sound in air on typical conditions is about 33cm for each ms, so if recorded with a microphone (rather than with a line-in) the distance from the speakers is utterly important.

I explored using my super-slow-motion settings in my phone to do such measurements, but in the end I was not able to achieve anything accurate enough and decided to go with "gut feeling" wrt what feels "right" when playing.

No test can truly be perfect as the testing overhead comes into play if running on the same system.

I've been recording 35 years and as many know, some latency is just too much. I tested this with  jackd.

jackd -R -P75 -t2000 -dalsa -dhw:1,0 -p16 -n2 -r192000 -s

Try sudo apt install linux-lowlatency
sudo update-grub

That way you’ll get the lowlatency version (which has all the tunings minus the hard realtime scheduling).

It might be a better balance.

RT can significantly degrade overall throughput, battery life, and preempt things you may not want preempted.

So if I am running a DAW with lots of plugins, I would test to see which kernel doesn’t impact overall throughput too much yet also allows low latency.

For a general use machine I’d probably just go lowlatency.

dikrek wrote:

What if you just use lowlatency and not the RT kernel?

I'm using the lowlatency rt kernel. Are you disappointed in these results?

I thought there was another kernel option with just lowlatency, not using the RT mode.

That is indeed impressive, but how did you measure that? More than the "declared" latency (which includes only what the software declaring it knows about), I think it's important to know actual latency. The only way I know to "scientifically" measure the latter is with a highly accurate high-speed audio-video recording device -- checking the time delay between your pushing down the key(s) and the sound being recorded.
It's very important to keep in mind that the recording device needs to have very tight sync between audio and video, and that the speed of sound in air on typical conditions is about 33cm for each ms, so if recorded with a microphone (rather than with a line-in) the distance from the speakers is utterly important.

I explored using my super-slow-motion settings in my phone to do such measurements, but in the end I was not able to achieve anything accurate enough and decided to go with "gut feeling" wrt what feels "right" when playing.

No test can truly be perfect as the testing overhead comes into play if running on the same system.

I've been recording 35 years and as many know, some latency is just too much. I tested this with  jackd.

jackd -R -P75 -t2000 -dalsa -dhw:1,0 -p16 -n2 -r192000 -s

What if you just use lowlatency and not the RT kernel?

I'm using the lowlatency rt kernel. Are you disappointed in these results?

- 0.2 ms 32 bit 192kHz 32 frames, small buffer
- 0.1 ms 32 bit 192 kHz 16 frames, small buffer
- 0.03 ms 32 bit 192 kHz 8 frames, small buffer

I am more than blown away with this.

That is indeed impressive, but how did you measure that? More than the "declared" latency (which includes only what the software declaring it knows about), I think it's important to know actual latency. The only way I know to "scientifically" measure the latter is with a highly accurate high-speed audio-video recording device -- checking the time delay between your pushing down the key(s) and the sound being recorded.
It's very important to keep in mind that the recording device needs to have very tight sync between audio and video, and that the speed of sound in air on typical conditions is about 33cm for each ms, so if recorded with a microphone (rather than with a line-in) the distance from the speakers is utterly important.

I explored using my super-slow-motion settings in my phone to do such measurements, but in the end I was not able to achieve anything accurate enough and decided to go with "gut feeling" wrt what feels "right" when playing.

dikrek wrote:

Why not the low latency kernel instead? RT has some drawbacks

I just bought a new laptop, installed ubuntu 25.04 with 6.14 RT + lowlatency kernel.

Latency is:

Default Lunar Lake integrated soundcard
- 1.3ms 64 frames @48kHz <- not bad at all but I will never even test that again as I never use integrated audio.

SSL 2 32bit 192kHz USB interface with lowlatency

- 0.2 ms 32 bit 192kHz 32 frames, small buffer
- 0.1 ms 32 bit 192 kHz 16 frames, small buffer
- 0.03 ms 32 bit 192 kHz 8 frames, small buffer

This is on a brand new ASUS Vivobook 16 Flip OLED TP3607SA-RJ019X Core Ultra 7

CPU: Intel Core Ultra 7-258V
CPU Cores: 8 Core || 8 Threads
RAM Size: 32GB DDR5
Storage Size: 1TB SSD Upgradable
GPU: Intel Arc iGPU
Screen Size: 16" QHD+ 120Hz OLED

I am more than blown away with this.

Battery life is a reasonable 8h (windows 11 proclaims to get 22h max but I installed ubuntu as a fresh install and never booted into it to test).

What if you just use lowlatency and not the RT kernel?

Why not the low latency kernel instead? RT has some drawbacks

I just bought a new laptop, installed ubuntu 25.04 with 6.14 RT + lowlatency kernel.

Latency is:

Default Lunar Lake integrated soundcard
- 1.3ms 64 frames @48kHz <- not bad at all but I will never even test that again as I never use integrated audio.

SSL 2 32bit 192kHz USB interface with lowlatency

- 0.2 ms 32 bit 192kHz 32 frames, small buffer
- 0.1 ms 32 bit 192 kHz 16 frames, small buffer
- 0.03 ms 32 bit 192 kHz 8 frames, small buffer

This is on a brand new ASUS Vivobook 16 Flip OLED TP3607SA-RJ019X Core Ultra 7

CPU: Intel Core Ultra 7-258V
CPU Cores: 8 Core || 8 Threads
RAM Size: 32GB DDR5
Storage Size: 1TB SSD Upgradable
GPU: Intel Arc iGPU
Screen Size: 16" QHD+ 120Hz OLED

I am more than blown away with this.

Battery life is a reasonable 8h (windows 11 proclaims to get 22h max but I installed ubuntu as a fresh install and never booted into it to test).

dubc wrote:

Chopin87 wrote:

Quick reminder that you don't necessarily need a modded kernel any more if you use a kernel from 6.12 onwards given RealTime patch was added to the mainline from that release.

I never knew that. Im still on https://liquorix.net/

Im going to look to update to 6.12 RT as long as pre-compiled exists. Turns out Ubuntu Pro is free for 5 installs and has RT included!!. I would defeinately pay if required. Yay!!!

Thank-you!

Also - I record only on linux and its many times better with stability than windows. Its easier to use once set up also. It allows me to really focus on the music.

I updated to the realtime kernel. That was a major pain. There is 5 free license for Ubuntu Pro Subscription https://ubuntu.com/pro/subscribe

Why not the low latency kernel instead? RT has some drawbacks

Chopin87 wrote:

Quick reminder that you don't necessarily need a modded kernel any more if you use a kernel from 6.12 onwards given RealTime patch was added to the mainline from that release.

I never knew that. Im still on https://liquorix.net/

Im going to look to update to 6.12 RT as long as pre-compiled exists. Turns out Ubuntu Pro is free for 5 installs and has RT included!!. I would defeinately pay if required. Yay!!!

Thank-you!

Also - I record only on linux and its many times better with stability than windows. Its easier to use once set up also. It allows me to really focus on the music.

I updated to the realtime kernel. That was a major pain. There is 5 free license for Ubuntu Pro Subscription https://ubuntu.com/pro/subscribe

Quick reminder that you don't necessarily need a modded kernel any more if you use a kernel from 6.12 onwards given RealTime patch was added to the mainline from that release.

I never knew that. Im still on https://liquorix.net/

Im going to look to update to 6.12 RT as long as pre-compiled exists. Turns out Ubuntu Pro is free for 5 installs and has RT included!!. I would defeinately pay if required. Yay!!!

Thank-you!

Also - I record only on linux and its many times better with stability than windows. Its easier to use once set up also. It allows me to really focus on the music.