Yes I heard the Mac drivers are better. For Windows they suck.

 

Generic ASIO. Everything works as expected.

 

Thanks for the info. I also was looking at all USB 2 and Thunderbolt interfaces when I was deciding which way to go.

 

Dunno if this has been mentioned here, but Linux provides a lower latency than Windows when using the realtime kernel. Obviously this uses more CPU but would indeed provide a lower latency, as well as more audio driver configuration options.
This is assuming you're willing to make whatever sacrifices comes with switching to a Linux distro!

 

Have you checked your PCIE lanes devoted to the Thunderbolt 4 port? You can use hwinfo under the buss section to see.

 

that was my recommendation for a build for the thread starter. My system is in the signature.

 

I’ve been reading through these posts and I really do understand the obsession of achieving super low latency of 3ms or less. I mean, who here wouldn’t want to go through life recording and mixing all projects below 3ms? But I think we all need to come down to earth and return to reality!

While it is possible to achieve a RTL latency of below 3ms with some devices today, the question is ‘under what circumstances this is?’. What are the criteria? How many tracks, how many plugins, how many real time VSTi’s can you handle while operating under 3ms?

The thing is that even today there still isn’t a standard that can compare one audio device to another to see how they compare performance wise?

So if someone states their interface can operate at below 3ms RTL it actually doesn’t mean anything! It only means they can lower the sample rate to 32 or even 16 to achieve this.

But what can they do while at this sample rate? Can they play 20 instances of Kontakt real time simultaneously while mixing 100 audio tracks with insert effects? I highly doubt it!

Hyped RTL latency numbers of a device don’t mean anything in the real life world performance.

I think it’s about time we get a standard that will let us compare one device to another to get an impression of what it can do in a real life performance? A number that will reveal the real life performance and not just the achievable RTL latency!

 

Make a CPU with 64GB of full speed L1 cache, make it be the fastest mfing CPU ever.

Also kill the I/O bottleneck that's been plaguing computers design since the IBM PC..
Think about the Lag you suffer when a HDD is off and a program needs to write, the whole system hangs momentarily, (or sometimes half a minute)
that's Bad Design, and it already happened with a 286, Windows 3.11 and floppy disks;
computers may be faster/better but they haven't really fixed that part yet..

Put the Fastest RAM in existence, in MHZ and Timings.

Program the OS completely in Assembly, Drivers and all.
Program a DAW in Assembly, bit by bit.. and make it Multithread capable, and VST3 compatible, etc etc..

When you're finished show me and I'll tell you the rest..

 

Last edited: Aug 6, 2023

Yes... but for what? Certainly not for (near real-time*) audio processing. L1 cache has a slight problem with streamed inputs/outputs. It's not predictable so it can't be cached.

System bus? ISA design? CPU stalls? Speed of light? User reaction speed?

What? I can't ever remember even using a 286 with Windows 3, as 386s were already out there in force. NT required a 386.

But I certainly haven't used a 386 for yonks anyway. We've had SSDs for professionals doing Real Work™ in the audio/video domains for a looong time, and decent HDDs could be switched to not turn off/sleep and had good enough caches to keep writing unless the total disk bandwidth was exceeded. Even faster HDDs never made it to home systems since SCSI wasn't used that much. People using HW samplers still use it. Eventually we got fast enough connections (SATA) and reasonably priced solid state drives.

No, the issue is that our general purpose CPUs are bottlenecked for some operations, on purpose, look up "memory hierarchy". This in the name of flexibility, expandability and cost-effectiveness. Businesses are still willing to pay top dollar for systems running their backend apps and databases for a good reason.

Sure, we've already got those. And you can't make L1 cache that big and even if some poor soul could either afford or even utilize it when you run past a few cores then that memory would be non-uniform.

Modern assembly suffers from the same issues as above. Even going to that level, we still can't influence the CPU core scheduler or the microcode. Apart from reeeally low-level hardware manipulation, the only use of assembly is to use vector instructions (your AVX et al). But AVX for a lot of purposes is: expensive to implement in hardware and software, and even when using such makes sense only certain operations can be vectorized.

In short: if you want the fastest audio processing unit you design a purpose-built processor for that. Something which we've had for a long time. DSP chips. Optimized for fast transfer across system buses, predictable real-time operation. What do you lose then? The biggest one is flexibility of course, DSP code can only be written one way really. And here's the thing: it's going to be expensive as fuck.

You won't get DSP chips running multitasking multithreaded operating systems. Good luck writing shit on the internet, surfing for porn, or watching YT on one of those. No, they'll process audio/video/etc. and nothing else.

...I think you can keep the rest to yourself now.

Apologies for the rant, it just gets me sometimes when people assume in computing that "Bigger Numbers" = "Better Performance". Here we're talking about a system, with a reasonable but not ultimate variable load, within a good latency, right?



*) by "real-time" I mean RT in the strict definition. General purpose OS's and devices can't be, as a hard RT system has a guarantee that an operation is performed in a guaranteed deadline. If this deadline is missed once it's a critical, total, system failure. Soft RT can tolerate the occasional missed deadline, but any operation missing one is deemed a failure. Both systems are "low-latency" by definition, but our systems are mostly just (very) low-latency not RT systems. That is, our systems are OK running with a given latency with some, non critical, failures. In audio streams that is a dropout/glitch.

 

SSDs are surely much faster, and NVMe is flipping awesome.. but still,
just because we don't notice this latency as much doesn't mean its not there..
it may be present in microstutters or something but the point is, it's a fault of design..

Exactly

Exactly

Lol.. well maybe that's what we need!

Or just a middle term between the two,
an audio interface is an example of that I guess, highly optimized for audio/midi I/O,
some of them can also do real-time DSP effects, but I haven't heard of doing that since the SB Live days..
(Powercore and UAD type stuff aside ofc..)

My post was highly Humorous.. don't take it too seriously

 

Last edited: Aug 6, 2023

Except for Dante which can run 32 x 32 channels @48khz sample rate on a Gigabit network @1 ms latency.

 

I don't know why they used Gigabyte port and not 10 Gigabytes ports.

 

It's not about obsession if you play a live instrument. It's about convenience. You will not have to freeze all your track to play live or adjust your playing style to compensate for the latency that will come.

 

I wouldn't doubt it for a minute! But the question is, what can he actually 'run' on this system? Can he run 32 instances of Kontakt with heavy libraries at 1ms?

 

Why are you using a StarTech Thunderbolt adapter?
You device is Thunderbolt 3 and so is your MB.

 

All of this is actually a non discussion! The effects of RTL also can be seen in what instruments or plugins you use. This determines how low you can go regarding Sample rate!
So if you just play one instrument live it makes sense. But if you also play other vsti's while playing a live instrument it becomes un-comparible! So just looking at the lowest latency a device can reach is just part of the story!

 

Last edited: Aug 6, 2023

Yes and No, If you have more bandwidth you can have better latency with more plugins than if you have less bandwidth with the same amount of plugins.

It's like your internet connection, 200, 400 or 1 gig. Which is better and will allow you to download faster and more streams?

Physics are physics. What I find so irking is how people in here are trying to not justify bandwidth and how much it plays a roll in obtaining near to 1 ms latency. Any person can do a basic google search to see that I and other are saying the same thing.
I wish people would stop trying to justify USB is just as fast as Thunderbolt or Dante. It's not.
Yes Freeze all of your tracks on USB and you can get a decent latency, Then record your live instrument then undo all the frozen tracks.
so you can adjust you other vst instruments. back to my point before convenience.

 

Last edited: Aug 6, 2023

for mixing and mastering (no for midi and vsti )
0 latency here . . . with old pc.
No use plugins, use only hardware.
Macs and pc have limited life, Decent hardware works for decades with no problems.
workflow is different, but is not so expensive
a small analog console with 8 buses and 32 channels and 3 racks with you favourite hardware....
Computer with a rme card for input and outputs.

no for mobile people, sorry

 

This thread can go on forever. I'm surprised it didn't turn into the usual "just use a Mac" battle, or did I miss that?

Imho, if OP wants latency like in the nineties like he said that's not 0ms but probably more 5 to 10ms or even more(?) Correct me if I'm wrong but even just a big chord is spread out over almost 10ms latency by midi standart with the cables. An old school Studio with lots of hardware and quite long midi cables is not 0ms. It was just harder back then to measure latency.

Just get literally almost ANY PC that's fast, Mac or PC, almost ANY interface of the last few years and you will have great sub 10ms latency for what OP wants to do. Time making music much better spent then discussing over 1ms here.

 

Last edited: Aug 6, 2023

So 16 instruments x 32 instance of Kontakt at 1ms? I don't think so. The only reason for wanting super low latency is if you're doing a live performance. Apart from that, latency doesn't really matter.