Maybe it could be an option in later PTQ-versions to select between 2 or 3 periods in ALSA output for those, who are manic and squeeze every millisecond from given hardware.

cheers

@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?

Yes, that's correct.

Are you saying that the latency on your ES3-PianoTeq has fallen from 22ms to 7-8ms?

For clarity, is that 7-8ms from finger triggering a key to sound output of say a headphone?

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

Really? See above:

gabe: ~ 20 ms, Kawai CA58
groovy: 22 ms, Kawai ES3
music_guy: 5 (?) ms, Kawai ES100

Are you saying that the latency on your ES3-PianoTeq has fallen from 22ms to 7-8ms?

For clarity, is that 7-8ms from finger triggering a key to sound output of say a headphone?

Thanks

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?

I found a nice PDF with the title Why do you need USB Audio Class 2?

Interesting info. Thanks!

The max. samplerate of 1st Gen is 96 kHz. So it only can be compliant to USB Audio Class 1 (UAC1).

The 2nd Gen is specified with 192 kHz samplerate, which means it could be USB Audio Class 2 (UAC2).

I found a nice PDF with the title Why do you need USB Audio Class 2?

Interesting are the Streaming differences (Table 6):

UAC   Streaming latency
-----------------------
UAC1  4ms
UAC2  500μs

That reminds me of the  3.9 ms static lag of my 2i2 (1st Gen) compared with onboard PCI-Audio. Could be the amount for UAC1.

On the other hand the Linux-kernel is supporting UAC2 for years now, so chances are good, that the Focusrite Scarlett 2i2 2nd Gen will have lower latencies with generic alsa-driver (should 2nd Gen really be UAC2 compliant).

PS: And it would fit in the picture, that I found the same latencies (@64 samples) with two other UAC1-Audiointerfaces, Behringer UCA-222 and Esi Maya22.

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

# aplay -l

Aha, I see. Following your example, it turns our this macbook has the Cirrus Logic cs4206.

7 Series/C210 Series Chipset Family High Definition Audio Controller, by Intel.

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

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

I have a hard time finding this in Mac OS, which I hardly use. It is a work laptop that I use for presentations mostly. If I boot the machine in Linux, I find that the audio device is: 7 Series/C210 Series Chipset Family High Definition Audio Controller, by Intel.

The old mac seems to do better than my relatively new (1.5 years) Windows 10 laptop (LENOVO YOGA 510-14ISK) which I specifically bought for the piano....

macbook air i5 onboard

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

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.

The plot thickens... I should stop doing these measurements and play the piano, but to satisfy my curiosity I did the same type of measurement on an old (~6 years) Macbook Air (i5). Same piano, CA58. Surprisingly the 2i2 does not scale with a factor 4, but it is much better now:

buffer size / latency PTEQ -> lag

2i2:

64    1.5 ms  ->  5 ms
128   2.9 ms  ->  8 ms
256   5.8 ms  -> 14 ms
512   11.6 ms -> 25 ms
1024  23.2 ms -> 48 ms

macbook air i5 onboard:

64    1.5 ms  ->  7 ms
128   2.9 ms  -> 10 ms
256   5.8 ms  -> 16 ms
512   11.6 ms -> 27 ms
1024  23.2 ms -> 50 ms

The both scale with ~ factor 2. And the latencies are good. And it plays well:  at the shortest latencies no noticeable artifacts. The i2i is 2 ms better than the mac hardware, in terms of latency.

I should add that I noticed that the pianoteq sound starts with a very low amplitude oscillation that I did not include in all measurements reported, because I wasn't sure what it was. It looks as part of the sound, though.If it is included that would shave off 1 ms from all latencies.

Despite differences in the specific latency function parameters with differing hardware and OS, it seems that the steeper slope of the 2i2 is a consequence of the fact that it is a USB device. I would guess that focusrite's Windows drivers are highly optimized and while they do not even support Linux, the slope on both platforms is the same: 4.

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.