Topic: Buffer 64 vs 128 samples experience

I wanted to test to see if I could feel the difference in latency between 64 and 128 samples. This could be of interest to others.

So I realized a little protocol with the help of my son.

He made 50 buffer changes between 64 and 128 samples randomly.
There was no discussion between us, no looks, no smiles, nothing. I did not have access to the pc. I just had to play and give an answer that I thought was the good one for each of the 50 tests, "64 or 128 samples".

After the 50 tests, the results are:
When the buffer was 128 samples, I gave the correct answer 12 times (13 faults).
When the buffer was 64 samples, I gave the correct answer 14 times (11 faults).

The Chi2 statistical test gives these results: x²=0,08 and p=0,78

This means that I did not demonstrate my ability to feel a difference in latency depending on whether the buffer was 64 or 128 samples.

This result can not of course be generalized, each pianist having his own sensitivity and each system having different specifications.

But for me and on my system (pc, Win10, i5 7600k, 48kHz, Babyface Pro) this debate is closed.
My buffer will be 128 samples since I see no reason to require my pc to work at 64.

Re: Buffer 64 vs 128 samples experience

Thanks for sharing your experience! This is also quite important since difference in CPU usage between 128 and 64 samples can be substantial.

Hard work and guts!

Re: Buffer 64 vs 128 samples experience

Thanks for sharing your individual blind test results, stamkorg!

It just lacks information about the objective existence of a difference in your test-signals and its degree. If something went wrong with your setup, maybe the latency is unchanged/identical and results have to be near 50:50. Another disturbance variable can be latency-jitter or a high, absolute latency on your system (I guess not but who knows?)

A quick test is to mouseclick PTQ's virtualkeyboard and to record the sound from the speaker and the clicknoise with a microphone (most every laptop or smartphone has a mic built in). In an audioeditor (e.g. Audacity) the latency between those two signals can be measured.

Re: Buffer 64 vs 128 samples experience

groovy wrote:

Another disturbance variable can be latency-jitter or a high, absolute latency on your system (I guess not but who knows?)

Not with a RME Babyface Pro it's not a problem.

Last edited by EvilDragon (30-09-2019 17:39)
Hard work and guts!

Re: Buffer 64 vs 128 samples experience

groovy wrote:

It just lacks information about the objective existence of a difference in your test-signals and its degree. If something went wrong with your setup, maybe the latency is unchanged/identical and results have to be near 50:50.


You're right, I did not objectively prove that latency really changed. But several times I asked my son to put the buffer at 2048 and I was able to verify on the keyboard that the latency increased then.
Except to consider a defect of my system there is no reason to think that the latency was not affected by the manipulations of my son. But in absolute terms you are right. Checking this point each time would have made the experience much heavier

Re: Buffer 64 vs 128 samples experience

stamkorg wrote:

But several times I asked my son to put the buffer at 2048 and I was able to verify on the keyboard that the latency increased then.

Good, then at least the settings were refreshed (as expected). But this alone is no guaranty, that everything works as expected at minimum buffers 64 or 128, transferred in 2 or 3 periods depending on software and hardware (and their interaction). Can be a bit hairy in this range.

In my opinion the latency of 64 and 128 has not to be checked "each time", just a few times before a blind test session starts. Then you can be sure about the dimensions and the fluctuations/jitter of your test-latency.

The overall-latency of your chain (key stroke to speaker...20 ms, 30 ms, 40 ms?) would be interesting too, because this is the basis when you add a few milliseconds by varying the buffersizes.

Re: Buffer 64 vs 128 samples experience

This is subtle so tough to design a robust testing scheme.

I would expect that it would be easier to discern differences with longer playing samples (say 60 seconds vs 15 seconds) which allow your musical mind & internal clock to settle in. How long was each test roughly?

You could test this by setting several test lengths of say 15, 30, 45, 60 seconds. Then see how the stratified stats look.

A few other thoughts

- If you are playing the same piece, over and over, maybe you get more aware. Then become bored, and less aware.

- if you are playing different material, then maybe some material is more timing sensitive,

- It might be better if you just had to identify changes in buffer size without prompt from your son. But there you might not have any data lol.

- etc.

groovy wrote:

The overall-latency of your chain (key stroke to speaker...20 ms, 30 ms, 40 ms?) would be interesting too, because this is the basis when you add a few milliseconds by varying the buffersizes.

This could make a difference maybe because of ratio of changes.

For example, on my system, I measure "total latency" of ~6ms from the noise of finger striking key to headphone output (buffer of 64 measured via Audacity). If I were running with speakers, the latency increases 3ms as sound travels say 1 metre more, for total of 9ms.

So if changing buffer from 64 to 128 increased latency by say 2ms, the ratio changes based on headphone or speaker use.

2ms / 6ms ~ 0.3333
2ms / 9ms ~ 0.2222

If your keyboard controller or computer is less efficient and your "total latency" were say 20ms, then changing buffer from 64 to 128 might be less obvious

2ms / 20ms ~0.100

groovy wrote:

Another disturbance variable can be latency-jitter or a high, absolute latency on your system

That could be an issue with faster playing and bigger chords as MIDI information "cues up" at the digital piano to go down the slow DIN midi cable (or maybe USB based on how raw sensor data is handled inside the digital piano). Somewhat less meaningful as all "tests" have same issue.

Re: Buffer 64 vs 128 samples experience

music_guy wrote:

For example, on my system, I measure "total latency" of ~6ms from the noise of finger striking key to headphone output (buffer of 64 measured via Audacity)

Do you refer to your "quick-and-dirty latency tests a few years ago"?
->
https://www.forum-pianoteq.com/viewtopi...05#p955505

Hard to believe without any proof, sorry.

Last edited by groovy (03-10-2019 20:36)

Re: Buffer 64 vs 128 samples experience

groovy wrote:
music_guy wrote:

For example, on my system, I measure "total latency" of ~6ms from the noise of finger striking key to headphone output (buffer of 64 measured via Audacity)

Do you refer to your "quick-and-dirty latency tests a few years ago"?
->
https://www.forum-pianoteq.com/viewtopi...05#p955505

Hard to believe without any proof, sorry.

Not really the point of the post but sorry for wasting your time.

Re: Buffer 64 vs 128 samples experience

groovy wrote:
music_guy wrote:

For example, on my system, I measure "total latency" of ~6ms from the noise of finger striking key to headphone output (buffer of 64 measured via Audacity)

Hard to believe without any proof, sorry.

Not to stray from the real topic... but do you really think 6 ms key strike to sound output is hard to believe?

Round trip audio latency of microphone/guitar input, through VST processing, back out to speakers at 6 ms isn't unusual or remarkable.  I haven't time the key strike to midi to DAW time, but is there any reason to think the midi in path would be slower than the audio in path?