Thanks for the reply.

I wiped the machine and installed Ubuntu Studio 26.04

All good!

... and yes, no crackling with a sample size of 64  ...  latency is 1.3 ms

Great!

Hello,

I think you should be able to run Pianoteq at 64 samples.

I see  3 important things to start : 

1. Install a low latency or real-time kernel
2. In Pianoteq there is a setting that maximize cpu use. Set it to Max
3. Use the power management to "performance" in Ubuntu

Also in jack there is a setting called "priority" if I remember. You could set it to 90

Did you try a Ubuntu Studio for this use ? It's easy and ready with low latency kernel.

Thanks for the reply.

I wiped the machine and installed Ubuntu Studio 26.04

All good!

... and yes, no crackling with a sample size of 64  ...  latency is 1.3 ms

I have almost the same computer you have, i7-7700 4 cores with 8 threads. I am not using jack, I am using a pipewire.

This advice I took from Glennbo in the Reaper forum:

"One thing I always find helps to achieve lower latency is to modify,

/etc/security/limits.conf

and add the two lines, (replacing USER_NAME with the name you see in a terminal window). Those lines let you run processes at up to 98% real time, and gives you unrestricted memory access.

@USER_NAME - rtprio 98
@USER_NAME - memlock unlimited

Note: There are also other ways to achieve this, where you add yourself to the audio group, and then set user audio with similar limits. It's just seemed like fewer steps to just give myself higher limits, and I might want to run something like video editing software that may or may not be in the audio group."

I am running Debian 13 stable and use a Gnome desktop. Every time I run Pianoteq I set my balance to performance mode, set Pianoteq to 48 kHz, set the audio buffer size to 128 and especially set my polyphony to auto pessimistic just to play without cracks and very, very few xruns. If you really like your performance and want to record, after the performance you can set much more polyphony in order to record, so you can render the audio with more polyphony.

I do that with an internal sound from the motherboard, but if you get an external sound card (I have a Steinberg UR22), I can get a lower buffer size without any problem.

I hope that will help you.

I've learned a few things here, but I'd like to learn more from others, so maybe this discussion will also help others. There's some discussion on reducing latency, but not so much on eliminating the crackling sound.

I've been using Linux exclusively for over 15 years, but I have found it difficult to get a stable sound from Pianoteq 9. I am using JACK, and the issue is a crackling sound while playing. To me, this is obviously an issue with audio processing not keeping up, and possibly causing extra latency (more on this later--needs to be better understood). My computer runs an Intel i7-4770 4-core (8-thread) CPU running @ 3.4 GHz, with 16 GB RAM, on Ubuntu 24.04, and the audio chipset is on the motherboard. This machine does no other tasks except process audio, and so it's a bit surprising that more tuning is needed, since this computer is no slouch! I followed all tips in the readme file, and have configured real-time scheduling for the audio user in /etc/security/limits.conf, and I've added my user account to the audio group. No issues there, since that fixed the error messages seen on the command line and reduced the latency to something that sounds fairly good..... but it still crackled.

After searching for better help, I found some discussion on this forum around lowering the audio buffer size from the default 256 to 128 to reduce latency (hoping this will also reduce the crackling), implying buffer size can be adjusted from within Pianoteq. This is not the case, however, since Pianoteq does not allow this value to be adjusted from within. After a lot of reading and fighting, I was able to adjust the buffer size from QjackCtl. So I adjusted the buffer size down from 256 to 128, which should reduce the latency from about 5 ms to 2.5 ms, however that resulted in a LOT more crackling. I don't really want to increase the latency, however I then increased the buffer size from the original 256 to 512, which increased the latency from 5 ms to 10 ms ... AND THAT REDUCED MOST OF THE CRACKLING! I should also note that I have the sampling rate set to 48 kHz.

So here is the first important takeaway from this discovery, which is not pointed out very well in the readme file or help on the forums: Buffer size needs to be adjusted to find a compromise between latency and crackling; a larger buffer size will reduce crackling at the expense of increased latency, and a smaller buffer size will decrease latency at the expense of more crackling. Generally, <= 10 ms of latency is acceptable, but > 10 ms is where it really starts to feel laggy.

So I have my buffer size set to 512, which gives me 10 ms of latency with very little crackling, but if I want to eliminate all crackling entirely, then I set the buffer size to 1024, which results in 20 ms of latency, which feels terrible.

So that brings me to my questions (for anyone who still cares). With 4 cores (8 threads) running at 3.4 GHz, I think I should be able to reduce my buffer size back to 256 with 5 ms latency without crackling.... so why is this a problem? I don't see how this software performs well on lesser CPU specs, but yet I am sure it does (too many videos out there where I hear no crackling at all). What is being over looked here? (I have also run the cpufreq-set command to put all 8 cpus into performance mode; this made no perceptible difference, as expected, since these CPUs are already powerful and doing no other tasks).

Any Ideas? for those in the know, please share your knowledge and experiences! THANKS!!

-Rob

Hello,

I think you should be able to run Pianoteq at 64 samples.

I see  3 important things to start : 

1. Install a low latency or real-time kernel
2. In Pianoteq there is a setting that maximize cpu use. Set it to Max
3. Use the power management to "performance" in Ubuntu

Also in jack there is a setting called "priority" if I remember. You could set it to 90

Did you try a Ubuntu Studio for this use ? It's easy and ready with low latency kernel.

I've been using Linux exclusively for over 15 years, but I have found it difficult to get a stable sound from Pianoteq 9. I am using JACK, and the issue is a crackling sound while playing. To me, this is obviously an issue with audio processing not keeping up, and possibly causing extra latency (more on this later--needs to be better understood). My computer runs an Intel i7-4770 4-core (8-thread) CPU running @ 3.4 GHz, with 16 GB RAM, on Ubuntu 24.04, and the audio chipset is on the motherboard. This machine does no other tasks except process audio, and so it's a bit surprising that more tuning is needed, since this computer is no slouch! I followed all tips in the readme file, and have configured real-time scheduling for the audio user in /etc/security/limits.conf, and I've added my user account to the audio group. No issues there, since that fixed the error messages seen on the command line and reduced the latency to something that sounds fairly good..... but it still crackled.

After searching for better help, I found some discussion on this forum around lowering the audio buffer size from the default 256 to 128 to reduce latency (hoping this will also reduce the crackling), implying buffer size can be adjusted from within Pianoteq. This is not the case, however, since Pianoteq does not allow this value to be adjusted from within. After a lot of reading and fighting, I was able to adjust the buffer size from QjackCtl. So I adjusted the buffer size down from 256 to 128, which should reduce the latency from about 5 ms to 2.5 ms, however that resulted in a LOT more crackling. I don't really want to increase the latency, however I then increased the buffer size from the original 256 to 512, which increased the latency from 5 ms to 10 ms ... AND THAT REDUCED MOST OF THE CRACKLING! I should also note that I have the sampling rate set to 48 kHz.

So here is the first important takeaway from this discovery, which is not pointed out very well in the readme file or help on the forums: Buffer size needs to be adjusted to find a compromise between latency and crackling; a larger buffer size will reduce crackling at the expense of increased latency, and a smaller buffer size will decrease latency at the expense of more crackling. Generally, <= 10 ms of latency is acceptable, but > 10 ms is where it really starts to feel laggy.

So I have my buffer size set to 512, which gives me 10 ms of latency with very little crackling, but if I want to eliminate all crackling entirely, then I set the buffer size to 1024, which results in 20 ms of latency, which feels terrible.

So that brings me to my questions (for anyone who still cares). With 4 cores (8 threads) running at 3.4 GHz, I think I should be able to reduce my buffer size back to 256 with 5 ms latency without crackling.... so why is this a problem? I don't see how this software performs well on lesser CPU specs, but yet I am sure it does (too many videos out there where I hear no crackling at all). What is being over looked here? (I have also run the cpufreq-set command to put all 8 cpus into performance mode; this made no perceptible difference, as expected, since these CPUs are already powerful and doing no other tasks).

Any Ideas? for those in the know, please share your knowledge and experiences! THANKS!!

-Rob