non-additive latency

Hi,

interesting, thanks.

A few questions to the procedere.

Is the audio-input of your Kawai fully analog and therefore with zero latency? Or is it A/D-D/A converted in the Kawai? (probably not)

How do you measure the time difference? In an audio-editor by finding the startpoint of the two pianosounds in one wave? An example would be nice.

It would be interesting, how the onboard audiocodec (PCI) of your laptop behaves in comparison to the USB-Audiointerface Scarlett 2i2.

cheers

A while ago, I performed some tests in a different way - easier in my opinion: record the same note on different tracks of a DAW, one coming from the digital piano, the other form Pianoteq. Look at the position of the waveform, done. But either way, you're always measuring apples and oranges...! I mean that the AD part (recording) also has a role to play.

I just checked this, the output from the laptop played over the laptop speakers, and the piano over the piano speakers. I.e. the test is not identical to the one of yesterday, but it captures more or less the difference one is interested in (latency difference to ears). The distance of the mic to either speaker system was short and the same, ~10 cm. I also now measured the key press to sound latency (by hitting the key fast with my nail to get an impulsive sound), this is ~ 20 ms on the CA58 (i.e from nail contacting the key to sound produced).

As to the onboard sound hardware/drivers:

In terms of latency the results are not nearly as bad as I thought as long as you find the right drivers. Here are the results:

driver and latency setting in PT -> overall real latency increase as compared to CA58

winaudio 48kHz / 192 samples, 4.0 ms -> 78 ms (44kHz was not possible)
winaudio exclusive mode  44kHz / 192 samples, 4.4 ms -> 14 ms (lowest setting available)
directsound 44kHz / 64 samples, 1.5 ms -> 77 ms (not usable for playing on this system, pops etc)
directsound 44kHz / 192 samples, 4.4 ms ->  115 ms

the ASIO4ALLv2 drivers (with onboard audio hardware):

asio4allv2 44kHz / 64 samples, 1.5 ms -> 10 ms
asio4allv2 44kHz / 256 samples, 5.8 ms ->  21 ms
asio4allv2 44kHz / 896 samples, 20.3 ms  47 ms

Focusrite scarlett 2i2, new somewhat improved measurements:

focusrite 44kHz / 16 samples, 0.4 ms -> 6 ms (not usable for playing on this system)
focusrite 44kHz / 32 samples, 0.7 ms -> 7 ms (not usable for playing on this system)
focusrite 44kHz / 64 samples, 1.5 ms -> 10 ms (a bit better than my measurement yesterday)
focusrite 44kHz / 128 samples, 2.9 ms -> 14 ms
focusrite 44kHz / 192 samples, 4.4 ms -> 19 ms
focusrite 44kHz / 256 samples, 5.8 ms -> 23 ms
focusrite 44kHz / 448 samples, 10.2 ms -> 44 ms
focusrite 44kHz / 896 samples, 20.3 ms -> 80 ms

Concluding: all in all it seems that the latency of onboard system (Realtek High Definition Audio) is not bad at all if you use asio4allv2 drivers or winaudio exclusive mode. The shortest latency (that is reasonably free of pops etc) can be obtained with asio4allv2 and focusrite scarlett, both adding 10 ms to the latency of the piano. From the nail contacting the key to sound is 20 ms on the piano, and 30 ms with asio4allv2 and focusrite scarlett (@ 1.5 ms PT setting).

The observation that I reported yesterday, that longer latency settings in PT lead to disproportionally longer actual latencies overall seems to hold across hardware.

If the DAW hardware is independent of the Pianoteq hardware, I agree with you.

But if that part is identical, then the difference is still valid, right? I.e. if you record on the same device (with a mic or analog input) in parallel the acoustic/analog output of the piano and the acoustic/analog output of the system that runs Pianoteq, then the latency difference is what you would experience when you are playing.

That's the result I also get with my test: the digitally recorded result for the analog piano output vs pianoteq is consistent with the given buffer size. What is left unexplained (to me and Gabe I guess) is the fact that when listening live to the result (not the recording) the delay increases non-linearly with the buffer size. If you do your test only with a minimal pianoteq buffer and listen at the same time, you don't hear much delay. Where does that non-linearity happen? The unescapable latency should be fixed whatever the buffer size and only be additively increased by the pianoteq buffer. The recording is, but not the live output...

My current setup for Pianoteq v6.2.2 is an Intel N4200 notebook with onboard audiocodec ALC255. Let's see, how the lag of this is compared to my Kawai ES3 Stagepiano.

The method used is a dual channel recording. Left channel is recorded from line-out of my ES3. Right channel is the headphone-output of my notebook. PTQ is triggered by MIDI from the ES3.

For example PTQ with 64 samples audio buffer at 44.1 kHz samplerate results in a lag of 7 ms versus ES3 internal audio:

Other common buffersizes from 128 to 256 samples increase the lag linearly in this environment:

                 
samples   buffer[ms]  lag[ms]
64           1.5            7
128         2.9            12
192         4.4            15
256         5.8            19

MIDI events used are C4 note-ons recorded on the ES3. I always used the second note, because there seems to be something like an wake-on-effect with the first MIDI-note. Maybe because CPU-upscaling starts, buffers are filled the first time or something. This effect needs a few milliseconds on my system, for example the 7 ms lag at 64 samples is 2 ms longer then (=9 ms).

Instrument in the test was Steinway D Player Clean with all default effects (like delay! and reverb) switched off.

cheers

The default delay in "Steinway D Player Clean" delays the dry signal with 60 ms. But it only has 3 % amount in the mix with the dry signal, so this effect has no impact on our topic, yes. The dry signal is always present.

Hi gabe,

I have a Focusrite 2i2 also, so I could check this USB-device too:

The 2i2 is worse than the onboard ALC255 in my environment. Every additional 1 ms PTQ audiobuffer increases the lag with 4.0 ms in other words.

With ALC255 every additional 1 ms  PTQ audiobuffer increases the lag just with 2.7 ms (see Trend Line Equation).

I have to amend, that I never had tried to tweak/optimize the USB-audiopath on that notebook. Maybe there is some hidden potential, looking at your interesting results with the 2i2.

... how do you mean that? The increase is proportional or are your axis scaled logarithmically? 

cheers

PS:
Below my raw values, sometimes image-hosters disappear or change their URL and all images and work are lost then.
--------------------------------------------------------------------------------
        ALC255    Scarlett 2i2
    [ms]    [ms]    [ms]
samples    PTQ audiobuffer    lag (PCI ALC255)    lag (USB Scarlett 2i2)
64    1.5    7    12
128    2.9    12    21
192    4.4    15    25
256    5.8    19    30
---------------------------------------------------------------------------------

Does Focusrite support the Linux-Kernel?

Unfortunate wording indeed. Axes are linear. It is proportional in the sense that there is a linear relationship, but I would have expected the effect to be additive. That is, that an increase of the buffer in PT would increase the overall latency just with that amount, as the latency by other factors such as USB etc would remain the same. In that case the slope of the line in our graphs would be 1. But it clearly isn't. In my case the slope is 2.0 for on-board realtek and 3.8 for scarlett. In the latter case, increasing the PT buffer for example with 5 ms increases the overall latency with 19 ms. Strange.

Good point. My measurements are:
PTEQ buffer duration (ms), scarlett lag (ms), onboard lag (ms)
1.5,      7.,     9.
2.9,     10.,   n/a
4.4,     16.,   n/a
5.8,     21.,   18.
11.6,   44.,   30.
17.4,   60.,   41.
21.8,   86.,   49.

I did some quick-and-dirty latency tests a few years ago and had much different results.

That might be due to RME ASIO drivers or user error but I tried a bunch of testing methods to make sure the results were reasonable, including recording everything with one mic on one channel only.

My approach was similar to that of Luc Henrion. I don't remember all the details but basically ran the following:

- Kawai es100
- MIDI DIN cable to BabyFacePro to PianoTeq laptop#1 back to BabyFacePro
- Recording output with Audacity on laptop #2

I tried recording on laptop #2 a few ways. For example, comparing headphone out of es100 to that of BabyFacePro. I also tried recording via mics: fingernail hitting key, MIDI signal from es100, sound from es100 speakers, sound from monitors connected to BabyFacePro. etc.

Time between fingernail hitting key and:

- es100 internal sound output of es100 headphone out was less than 5ms and fastest I recorded.
- es100 to BFP to PianoTeq to BFP headphone out was just a bit more than 5ms (I think with PianoTeq at say 48KHz and a buffer of 64)
- PianoTeq had somewhat lower recorded latency than I could obtain with some sampled VIs; felt lower also.

Not sure why the es100 internal sounds are so fast. Onboard es100 Keyscanning, processing and MIDI buffering? Optimised onboard hardware and software?

Loudspeakers added about 4ms of latency to player position, which made sense given distance was a bit more than 1 metre.

Regardless, at these levels I don't notice a difference in latency between es100 internal sounds and PianoTeq via said chain.

I found some useful Information in the latest README_LINUX.txt from Pianoteq v6.2.2:

"* with Jack or Alsa, use buffer sizes that are multiple of 64, as Pianoteq prefers those
   sizes. With the Alsa driver, the latency is 3 times the buffer size (a buffer of 64 samples at
   44100Hz gives a latency of 4.3 ms)."

I guess that is a corrected version of the text in Pianoteq v5:

" - with Jack or Alsa, pick-up buffer sizes that are multiple of 64, as
   Pianoteq prefers those sizes. With the Alsa driver, the latency is
   2 times the buffer size (a buffer of 64 samples at 44100Hz gives a
   latency of 2.9 ms)."

So if the new README is correct, the best theoretical slope we can expect with Alsa drivers is 3 ("latency is 3 times the buffer ...").

Let's look at my regression lines:

PCI ALC255: f(x) = 2.7x + 3.4
USB 2i2: f(x) = 4.0x + 7.3

The on-board-PCI with slope 2.7 is near the theoretical minimum 3. The usb-audio-path with 4.0 is just a bit more sensitive for buffer size changes in a negative way.

What about the other constants in the equation?
ALC255: 3.4 (ms)
2i2: 7.3 (ms)

In my interpretation the 2i2 path is constantly 3.9 ms behind the ALC255 (7.3 - 3.4 = 3.9) and the dynamic increase/slope is superimposed.

A conclusion could be:

* The Alsa driver for USB (snd-usb-audio) has not ideal slope of 3 like the Alsa driver for the Realtek ALC255.

* USB-Audio at best lags 3.9 ms behind the PCI-Path on my PC-system.

* My 2i2 is 1st gen, gabe's 2nd gen. Maybe the newer hardware has less latency or the USB audio-driver is better latency-wise or something I don't know .

PS:
I guess the weak point is the snd-usb-audio, because I have the same latencies with two other USB-Audiointerfaces .

I agree with you.

But I don't know, if Focusrite is to blame. The Scarlett 2i2 (1st gen) is USB Class Compliant and works fine on Linux, just the latency for realtime is not the best on (at least) my Linux-Kernel.

Just for curiosity - which vendor/chipset is the onboard codec on that macbook?

Sorry, but thanks for your efforts!

That is just the controller at the PCI-bus, often shortnamed "Intel HDA" type.

Analog to the output of a (Samsung-)notebook for example:

# lspci | grep Audio
00:1b.0 Audio device: Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller (rev 04)

The audiocodec behind that controller is an Realtek ALC269V in this example:

# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC269VC Analog [ALC269VC Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Thank you!

EDIT:
Scarlett is using Cirrus Logic too.
Interesting document about latency of 2i2 1st and 2nd gen here:
http://caulixtla.com/JP-08/2i2.html

Why not ask to Focusrite directly? Their after sales service is good.

In comparison my new 2i2 2nd gen (B-Stock) has better latency, than 1st gen.

I installed JACK Audio Connection Kit and jack_iodelay to determine the Round-Trip-latency. Output and input are looped with a patch-cable. Settings in jackd 44100 Hz, 64 samples, 2 periods.

Two examples:

2i2 1st:
   520.655 frames     11.806 ms total roundtrip latency
        extra loopback latency: 328 frames
        use 164 for the backend arguments -I and -O

2i2 2nd:
   359.706 frames      8.157 ms total roundtrip latency
        extra loopback latency: 167 frames
        use 83 for the backend arguments -I and -O

But that was in JACK's default asynchronous mode, which means one extra period is used (2 + 1 = 3). With jackd -S prefix the daemon is started in synchronous mode and really 2 periods are effective. Result is a slightly better RT-latency, example:

2i2 1st:
   468.655 frames     10.627 ms total roundtrip latency
        extra loopback latency: 340 frames
        use 170 for the backend arguments -I and -O

2i2 2nd:
   307.706 frames      6.977 ms total roundtrip latency
        extra loopback latency: 179 frames
        use 89 for the backend arguments -I and -O

Without JACK and just ALSA directly in PTQ the new hardware although was just 1 ms better than the 1st gen Scarlett, not really significant.

But using JACK in synchronous mode with Pianoteq I have won 4 - 5 ms now. In other words, compared with my Kawai ES3 the 1st gen had 12 ms lag, while 2nd gen (and JACK) has a lag of just 7 - 8 ms now.

That is practically the same lag I had with the on-board Codec (7 ms). Fine.

For the next time I will play PTQ with the 2i2 2nd gen.

@modartt
Does the change from "2 times" to "3 times" in your newer README_LINUX.txt mean, that PTQ feeds ALSA with 3 periods of 64 samples in this scenario since v6.x, while JACK can feed ALSA with a minimum of 2 periods in synchronous mode?

No, the internal sound at the line-out of my Kawai is just a reference point. My notebook with PTQ v6.2.2 has always a lag / delay compared to that (both sound-engines are triggered by the same midi-event from the Kawai). All the times are just relative.

For the concept see my 12th post:
https://www.forum-pianoteq.com/viewtopi...73#p955473