for Linux go with default (usually PulseAudio - JACK is old hat nowadays) and buffer 128 samples at 44.1 or 48 kHz
don't run other programs you don't need at the same time as using Pianoteq
for Linux you can install a low-latency kernel and run PTQ and audio stuff at high priority but I found no need for it lately (though I do run a low-latency kernel)

Sorry, I strongly disagree on the PulseAudio thing. Did you know, that for example PulseAudio uses the crappiest sample rate conversion it has by default? Which is crazy when you run your sound card at 44,1khz, when most of YouTube is 48khz. Or you run it at 48khz and most of your music collection is 44,1...  When I first heard it I first tjought my digital console (which does the DA conversion) was broken.

On Linux, Jack still is #1 choice for pro audio, and in kxStudio is the default. PulseAudio is bridged to Jack for interoperability.

The low-latency kernel is good and I would generally advice to use it when doing realtime audio. However, it also consumes more computing power as the scheduler interrupts processes more often. (Processes get their turns faster, so that they can feed buffers in time.) You may notice that noisy fans turn on earlier when using a low-latency kernel.

I doubt that you will be able to go down to 64 samples without Jack and a low-latency kernel, the latter will be needed at least on slower machines. However, on kxStudio, one will notice that the PulseAudio bridge and even the ALSA bridge may screw up at 64 samples.

Then:
for Windows install ASIO set buffer to 128 samples at 44.1 or 48 kHz
for Linux go with default (usually PulseAudio - JACK is old hat nowadays) and buffer 128 samples at 44.1 or 48 kHz
don't run other programs you don't need at the same time as using Pianoteq
for Linux you can install a low-latency kernel and run PTQ and audio stuff at high priority but I found no need for it lately (though I do run a low-latency kernel)

I work mainly as an audio engineer, both live and in recording. Note that today most mixing consoles are digital. Plus, in any larger venue you will encounter digital stage boxes that transmit the audio via an ethernet protocol of some sort. These things both also add latency. Thus, when you have a 1,3msec latency, you can add the round trip to the digital console and back to your stage monitor or in-ear plugs. Things start adding up!

Me and myself, I use 64 samples either with a Scarlett Solo USB interface or a very old RME Digi PCI card on kxStudio Linux 18.04. As others here, I can feel 256 samples as unacceptable, 128 is fine. But since other factors for latency might pop in (see above), I go for 64 samples, which is about the smallest buffer I can use without disaster. :-)

Plus, if you use PianoTeq not standalone but as an LV2 plugin within Carla, the MIDI processing inside Jack will also suffer from the same latency setting as the audio. Which perhaps even makes sense, as incoming MIDI and audio data may be guaranteed to arrive at a Jack client at the very same time. But it doesn't make much sense for playing software instruments realtime.

Best
Schwob

https://expressiveelectronicsformusicia...y-analyser

I'm also curios if it's possible to adjust PNOscan to simulate the real piano latency, which is shorter for higher velocitie. Again, considering latency after the key reach key dip, since PNOscan use real piano actions (instaled on it) and thave the mechanic natural latency about the time required to the key go from the top to the bottom.

Yamaha Avantgrand have the sensor near the hammer, in the hammer's arm (shamk), so I believe it simulates all the natural grand piano latency, plus a electrical signal latency.

Is all MIDI-USB convert cables slowe than the older one, the MIDI-joystick cables to connect in the game port of soundcards some years ago ?

Philippe knows everything about real pianos.

The digital piano have some "mechanical lattency" too, since the hammer action key only start pressing the sensor (two sensor to define the note velocity) after  the key reach some depth, and there is a delay between for it hit each sensor, and this delay (from sensor 1 to sensor 2) creates a number that gives the key velocity.
In real pianos it's the time for the key to move the mechanism, that will impulse the hammer to hit the strings.  But I personally do not consider it as a real latency, despite it technically be correct, cause I only consider as delay, a feeling of delay, after the key reach the botton and give that "knock".
The "knock" feeling we get in the point of the finger, when the key reach the bottom, is the start to me, my brain do not intent the hear anything in the time between start pressing a key and the "knock"  sensation.  I presume for other people it's the same thing, otherwise much people would complaim about real pianos. 
Of course there is a very small space of time after the key reach the botton of the key dip, and the hammer hit the strings, since there is a point where the hammer is realeased and goes alone, but this short time appears to do not disturb anybody.
The higher velocity, the lower these latencies will be. Maybe the relation it's one thing that helps our brain to see it as natural in real pianos.

https://www.youtube.com/watch?v=aGY87KUuz8E

About the damper pedal, people would find strange if the damper effects would react imediatelly after the feet touch the pedal. Again it's logic to our brain wait some response only after some portion of the damper move. But I feel that real pianos are not like progressive digital pedals for digital pianos. I had not played many grand pianos, but in the few I palyed the sustein only started to work after the pedal have already move the majoroty of the portion it was able, so it worked very near the botton, and it make halp pedaling considerably more difficult in real grands than in digital pianos with progressive sustein pedals.

I was wondering. What about get a real concert grand piano action, adapt to PNOscan, and set pNOscan to the best latency, and use the best conncetion possible to competer, like EvilDragon use ?
PNOscan use velocity optical sensors that measures the velovity of the key. I imagine it do not need to wait until the wood key reach the deep bottom until send the MIDI signal.
So we would make a experiment:
We set PNOscan to have the best latency possible, probably better than real pianos, and get a pianist to play it . Would he imediately find it strange or not ? Better or worse to use ?
We then allow hin for 2 or 4 weeks, and no other real piano or other digital piano.  After that we allow hin play a real grand.  Would hin, after that, find the Grand piano latency anoying ?

http://www.speech.kth.se/music/5_lectur...asure.html

And here the interaction of the delay between pressing and hitting the string depends on the dynamics is interesting.

http://www.speech.kth.se/music/5_lectur...ybott.html

At the fortissimo, the hammer strikes the string later than the key reaches its bottom. And the pianissimo delay between the sound and the bottom of the key can reach up to 20 ms (earlier) ..
Hmm .. how much is this dependence implemented in Pianoteq? I'll go play and listen ..

Apparently this is possible only with optical tracking of the hammers, but not with the sensors of conventional keyboards, which are located almost at the bottom of the key ..

https://www.cakewalk.com/Support/Knowle...Technology

My Midi-USB cable, Cakewalk UM-1G, uses this FPT

But some people who used multiple speakers may want to compensate the speakers distance to be more coherent with mic distances, something like that. For example one mic in the rear end of a pianoteq concert piano and other mic in the front, but he places of speaker to each. That's why there is the sound speed slider, but I'm not sure if the minimal and maximal difference in tat slider is enough for all case scenarios.

And there will be always some fanatic people who will ask crazy things, like the latency or delay adjust  due mic's cable lenght.

I'm also confused about the asio4all driver I installed and the UM-1G driver I installed. Which one is working, or both works ?

But I supose our brains are already trained to interpret real world latency as normal, and this incluse our nerve system latency.
I remamber Philippe once commented about the latency in a real piano, and it was usually higher than the pianoteq latency (not counting USB and digital - analogic conversion)

This makes think... If a concert grand piano would have latency difference from the front to the back, and the final sound heard by the player would be one, due delays related to his ditance to the several piano components and to large conmponents specific places (beging or end of soundboard and harp cabinet piano body)

While a distant audience would hear a more "normal" sound, since the distance between the piano components would be relatively irrelevant to the main distance of piano to audience.

On pianoteq I presume all this is simulated. So you could be able to get close to a "latency free" sound between piano components by increasing the sound speed adjust and placing the mics far away.
But the sound speed slider goes only up to 500meters/second.
Why not a option to turn sound speed almost infinity ?