Focusrite Scarlett range refresh

[CrocoDuck]

Did I get it right?

Yeah I think so:

The "extra loopback latency" is latency not produced by jack itself. It is mainly down to the AD and DA converters in your soundcard.

The rest of the latency depends, of course, on jack settings. In this test, I am running jack2 in the default, asynchronous mode, with 1024 frames per period and 2 periods per buffer. So, 1024*2 + 1024 = 3072 frames

From this thread,

Focusrite webpage does not specify it, but I think they are referring to the soundcard related roundtrip latency only. It wouldn't make much sense to include software latency and I bet they would publish the smallest number they can get. We could try to see what the latency is using their very same setup: 48 kHz - 32 Samples and 96 kHz - 32 Samples.

Could you guys give it a try as well?

Sure! I bet it will be the same for us.

[gimmeapill]

Ok, here's mine with the first gen 2i2:

48Khz * 64 Frames * 3 Periods

Code: Select all

   621.635 frames     12.951 ms total roundtrip latency
        extra loopback latency: 493 frames

96Khz * 32 Frames * 3 Periods

Code: Select all

   458.626 frames      4.777 ms total roundtrip latency
        extra loopback latency: 394 frames

96Khz * 64 Frames * 3 Periods

Code: Select all

 690.627 frames      7.194 ms total roundtrip latency
        extra loopback latency: 562 frames

96Khz * 128 Frames * 3 Periods

Code: Select all

 1142.626 frames     11.902 ms total roundtrip latency
        extra loopback latency: 886 frames

Disclaimer: I'm testing with Jack1 - which should be in theory equivalent to jack2 in synchronous mode.
At least the numbers look consistent with what you guys posted.

So it is actually possible to compare the latency figures between different cards if we rely only on the extra loopback latency line - which should not be configuration dependant (save maybe for the length of the audio cable).

That's neat! no more hidding!
What about starting a latency benchmark page that will upset manufacturers?
I'm 99% certain users of other OSes might like to see that data as well...

[CrocoDuck]

So it is actually possible to compare the latency figures between different cards if we rely only on the extra loopback latency line - which should not be configuration dependant (save maybe for the length of the audio cable).

That's neat! no more hidding!
What about starting a latency benchmark page that will upset manufacturers?
I'm 99% certain users of other OSes might like to see that data as well...

Electrons travel conductors at a very slow derive speed, but the whole perturbation (signal) moves very close to light speed (sorry, that's me being a physicist...). Unless you have kilometres of cables it will never pay a role. I think controllers and hubs are actually much more conspicuous sources of not-souncard related latency which is not software latency. They should add up to few microseconds unless something bad or weird is going on. Other software delays would be at the kernel level, which should be microseconds as well.

To smear out all these effects we just have to do stats on a high number of measurements (more then 10 at the very very least).

Indeed, store up this sort of data was something in the back of my head. I can write down a Julia routine to measure latency and frequency response as the one I attached few posts ago. Moreover, I could add distortion measurements, crosstalk and few other things. I think that by using jack it can be made fully automatic. This way people would finally know what they buy... But I bet few companies would not like it at all: they never published detailed figures for a reason I would say. Is not that they have not these data: they are absolutely needed for the design and testing of the products...

I will try to speed up the coding of my measuring script. I am going slow because I want to learn proper Julia coding. But the prototype is working.

[CrocoDuck]

The lastest measurements of my old generation Scarlett 2i4

96000Hz, 64 buffer, 3 periods/buffer

Code: Select all

   636.753 frames      6.633 ms total roundtrip latency
	extra loopback latency: 380 frames
	use 190 for the backend arguments -I and -O

48000Hz, 32 buffer, 3 periods/buffer

Code: Select all

   361.694 frames      7.535 ms total roundtrip latency
	extra loopback latency: 233 frames
	use 116 for the backend arguments -I and -O

96000Hz, 32 buffer, 3 periods/buffer

Code: Select all

   450.753 frames      4.695 ms total roundtrip latency
	extra loopback latency: 322 frames
	use 161 for the backend arguments -I and -O

Seems to me that it is performing as the new model is advertised to perform... I am curious to see if the figures for the new gen are lower.

[gimmeapill]

...and also that your 2i4 1st gen is performing slightly better than my 2i2 1st gen in a rather consistent way - I don't like that
I'll rerun the tests with jack2 in async (default) mode - just to be sure...

Electrons travel conductors at a very slow derive speed, but the whole perturbation (signal) moves very close to light speed (sorry, that's me being a physicist...). Unless you have kilometres of cables it will never pay a role. I think controllers and hubs are actually much more conspicuous sources of not-souncard related latency which is not software latency. They should add up to few microseconds unless something bad or weird is going on. Other software delays would be at the kernel level, which should be microseconds as well.

Confirmed. I don't grep physics or maths, so I did test with a 10 meter xlr cable with xlr -> jack adapters, another 5m jack cable, and didn't see any noticeable difference with a 15cm patch cable.

The only things that seem to matter (as I think we discussed a few months ago):
- cross connecting (output X to input Y)
- perf differences between channels (output X -> Input X, output Y -> input Y,...)

Not sure if it is in the scope of your script to test all possible wiring combinations (I don't see it as very practical for the users, but still possible),
so I think the input/output # should be also mentioned in the results.
And maybe a simple disclaimer like: "those figures were produced by connecting only output 1 to input 1, number may vary with other combinations."

Another idea since we talk about benchmarks (sorry, I'm drifting again off topic): you could maybe approach the guys from Phoronix or make a post on their forums. They sure do love benchmarks and could maybe have some valuable input, or host the results...

Lastly, I just noticed that the European prices of the first gen have started to drop significantly (you can get roughly 1 model above if you go with 1st gen): http://www.thomann.de/cz/focusrite_usb_ ... tml?oa=pra

Cheers,

LX

[CrocoDuck]

...and also that your 2i4 1st gen is performing slightly better than my 2i2 1st gen in a rather consistent way - I don't like that
I'll rerun the tests with jack2 in async (default) mode - just to be sure...

Comes as a surprise to me, I would have expected pretty much the same numbers... Probably they use a converter of the same series but different model. Not sure whether the difference is statistical (i.e. different devices are not exactly identical) or it is a difference due to having a different chip in place... Still, the difference should not pay much of a role in terms of audibility, so we can say the cards are pretty much the same. Which makes me even more curious to know latency figures at 32 bits for the new gen (@spid4).

And maybe a simple disclaimer like: "those figures were produced by connecting only output 1 to input 1, number may vary with other combinations."

This should do. The only thing that is needed, for any kind of measurement, is to clearly state the conditions at which it was performed, so that it can be understood and reproduced.

I will have a look at Phoronix. My script should be (hopefully) ready by the end of the week. I think I will make a post somewhere, times are not mature enough for a github repo.

[gimmeapill]

Quick update: jack2 tells the same story regarding that extra loopback latency:

96000Hz, 64 buffer, 3 periods/buffer

Code: Select all

   687.627 frames      7.163 ms total roundtrip latency
        extra loopback latency: 431 frames
        use 215 for the backend arguments -I and -

I get 431 frames where you get 380 and that seems to translate into 1/2 ms of additional latency. Not totally negligible...

[CrocoDuck]

Not totally negligible...

Perceptually speaking, I think it is as long the whole latency is below 10 ms. For electronics it is a very long time tho, so I guess our units mount different converters.

[spid4]

Hi All,

Here are some more test results from the 2nd generation 2i4, including 32 frame buffer examples:

48KHz, 32 buffer, 3 p/b:

Code: Select all

287.772 frames      5.995 ms total roundtrip latency
	extra loopback latency: 159 frames
	use 79 for the backend arguments -I and -O

48KHz, 64 buffer, 3 p/b:

Code: Select all

403.767 frames      8.412 ms total roundtrip latency
	extra loopback latency: 147 frames
	use 73 for the backend arguments -I and -O

96KHz, 32 buffer, 3 p/b:

Code: Select all

277.504 frames      2.891 ms total roundtrip latency
	extra loopback latency: 149 frames
	use 74 for the backend arguments -I and -O

96KHz, 64 buffer, 3 p/b:

Code: Select all

477.505 frames      4.974 ms total roundtrip latency
	extra loopback latency: 221 frames
	use 110 for the backend arguments -I and -O

96KHz, 128 buffer, 3 p/b:

Code: Select all

853.495 frames      8.891 ms total roundtrip latency
	extra loopback latency: 293 frames
	use 146 for the backend arguments -I and -O

So it looks consistently faster than the first generation. At 96KHz * 32 * 3 the total latency would be about 4.5ms - pretty zippy. I do seem to be getting more xruns on that combination though.

[gimmeapill]

So it looks consistently faster than the first generation. At 96KHz * 32 * 3 the total latency would be about 4.5ms - pretty zippy. I do seem to be getting more xruns on that combination though.

Nice, thanks for testing.
xruns at 96KHz * 32 * 3 are quite expected, I don't think this would be usable for much except very light workloads.
If I got it correctly, the lower AD/DA latency won't reduce xruns by itself, but it will allow you to run with jack settings easier on the system and still get good performance compared to the previous generation.
Ex: instead of running at 96KHz, 64 buffer, 3 p, and get ~7 ms (with the first gen) you can run at 96KHz, 128 buffer, 3p and get 8.8ms which is still ok-ish for real time use, but should help significantly with xruns.
And if your system runs ok at 96KHz, 64 buffer, 3 p, then latency is <5ms round trip which is great

That alone makes the 2nd gen quite interesting actually - provided you are concerned with latency.

[CrocoDuck]

Nice! Thanks for the measurements.

So it looks consistently faster than the first generation. At 96KHz * 32 * 3 the total latency would be about 4.5ms - pretty zippy. I do seem to be getting more xruns on that combination though.

Appears faster indeed. Nice to know that if you are aiming to minimize latency you are not wasting money upgrading!

Well, one that wanted to be sure within a stated statistical confidence level would take repeated measurements with different computers... but we are not a research centre unfortunately... This info is enough for the time being

96KHz * 32 * 3 is indeed pushing the system a lot, and one can expect the software to hardly keep up. Pretty interestingly my box seems to be able to handle it now... some recent update must have improved the situation...

On the frequency response side: bugs in the Julia package I am using to stream the measurement signal broken my measurement script. I will rewrite it to stream audio with sox or ecasound and use temporary files. Not optimal but it should work until things are fixed on PortAudio.jl side. Still, it will need more time than expected...

[idrojsnop]

OK! and besides the measurements.. does the second generation of Focusrite Scarlett work under Linux?

Given that most users use Ubuntu-based distros, does it work under Ubuntu?

Through Internet there is no evident answer to these questions, let's try to answer it clearly for the record.

Jordi.

[raffguitar++]

OK! and besides the measurements.. does the second generation of Focusrite Scarlett work under Linux?

Given that most users use Ubuntu-based distros, does it work under Ubuntu?

Through Internet there is no evident answer to these questions, let's try to answer it clearly for the record.

Jordi.

Hi Jordi,

From my experience, I think it is safe to say that it works in Linux, and Ubuntu in particular (see my earlier posts on page 1). It worked for me without issues using KX Studio 12.04, AVL 6.0.4, (..but NOT 2016, however that might be specific to my machine because I have a few other issues w/AVL 2016), and Studio 13.37 which is Puppy. Also, a Focusrite representative said that, although they don't officially support it, it has been known to work in Linux because it is Class Compliant ( I'm paraphrasing here). So I guess we just need to hear from the people that are using Fedora, Arch, etc to make it official.

[Norlick]

Just confirming that my Scarlett 2i4 Gen 2 runs perfectly. Plug and play, recognized by everything, no problems.