I would try to borrow a newer interface for testing.
It looks like your computer is at the limit with the amount of VSTs.
Another interface will not help.
If the other interface comes with even more input and output channels (Madi), it gets worse for the computer.
I would test a Babyface Pro or just a Digiface USB.
The UCX ll is probably what comes closest to the FF400 by the inputs and outputs if you need those.

I agree, I would avoid Intel's big-little CPUs. That is anything above 11th gen.

Last few years, IMHO, AMD CPUs give better results comparing to Intel....

I cannot tell for games, I do not play....

In our case, music plays main role, I guess. Intel's big-little simply cause problems, unless DAW/audio SW is designed with big-little in mind, and people are often forced to disable e-cores....

Beside that, current Intels run far from optimal point. In fact, Intel sells heavily overclocked CPUs. And that means, they consume too much, need very good cooling and so on. Intel might have at some models slightly better single core performance, but it is not able to maintain that performance, if more cores are used.... Looks nice in tests, but not so nice in practical life.

Intel will use chiplets soon (or already uses in some CPUs), Apple uses chiplets as well in Mx Ultra CPU. AMD used to have problems with latencies with the first gen Zen CPUs, they learned a lot and redesigned things. On contrary latest Intels have severe latency problems if OS decides to realocate thread from e-core to p-core or vice versa...

I do not have proof, but I guess big cache might be beneficial for plugins that need a lot of memory.

I agree, things are not black and white. Not only CPU play the role and so on... Each platform has its advantages and disadvantages.

I have miniPC based on AMD 5700G APU, and I am satisfied. It works fine. My next PC will have future comming Zen 5 or Zen 6.

Program may set afinity to individual cores and so forbid using of certain cores for given program. Maybe that program may also say I want to run this thread on this core, but I am not sure.

Otherwise OS handles it, but not satisfactory. Imagine, one thread may be softsynth. It does not play at the beginning so OS places it to e-core, synth starts playing and dropout.... If application does not take care about the things and let it on OS, big-little will struggle....

AMD will also introduce big-little, but little will be big just with smaller cache.... So, not so much performance difference, just less silicon needed....

So, regarding cores/performance cores vs. e-cores.

This is actually quite interesting and I'm not sure how the following cores compare to each other.

The 10850K have 10 cores, which I guess is the equivalent of the e-cores in the 13900K, right?
Although, the 13900K have 2 less of these, "only" 8 performance cores!
Are the 8 performance cores of the 13900K still more powerful than the 10 cores of the 10850K? They should be, but what do I know.

This has actually been worrying me a bit, the e-cores.
I have no idea how well Cakewalk would utilize the p- and e-cores of the 13900K, mainly due to the new e-cores of which there are none on the 10850K which I'm currently running.

And finally, regarding upgrading my RME audio interface (FF400), to a newer one.

I've read your posts and the links and trying to get my head around it and what all that means. I'm not that very familiar with how all that works technically, and thus I might even interpret the information in the wrong way. Once again, I'm so pressed by the lack of time, and I currently do not have the time to deep diving into the realm of audio interface engineering and how it all works.

Therefore I've not managed to fully understand whether it would give me a noticeable speed (latency in DAW) improvement to upgrade from FF400 to a much newer interface. With latency in DAW, I mean the time between pressing play and starting to hearing audio without glitches etc.
If I use the smallest buffer, there are glitches and dropouts and it is all horrible. With the largest buffer chosen, this goes away, but of course it is slower to manoeuvrer/handle due to the larger buffer size and bigger latency chosen.

I run Windows 10 by the way.

So, as my projects get larger and I start to get dropouts, glitches, clicks and pops etc. I can do the following things to doctor/cure the problem.

1. I can decrease the number of tracks. (doing as much as conveniently possible already)

2. I can freeze tracks so the VSTi's/VST FX aren't running live. (doing as much as conveniently possible already)

3. I can increase CPU power (obviously). (as told earlier, this I'm planning to do, should it give the expected results)

4. I can increase buffer size for the audio interface, and thus also the latency. (already on MAX buffer size with the highest latency, so there's not more to do here.. thus the question, NEW RME audio interface?)

5. I can enable multicore optimization either in the DAW, the VSTi, or both (when available). (already doing this)

6. Did I forget something?

I'm trying to get my head around all the info regarding latencies and how audio interfaces work, but I might be too stressed to grasp what all that means. Therefore I still can't really understand whether a newer RME interface would allow me to decrease buffer size without the dropouts, glitches, clicks and pops, something which I unfortunately get when I decrease buffer size with the FF400.

And once again, this is regarding internal audio playback with wave files and VSTi's and such.

And yes, I understand that a faster CPU will help with this, since the audio interface is not an audio accelerator, like for example a 3D graphics card for games. (unfortunately) ..but still, I really can't understand the possible differences in audio handling regarding buffer sizes/latencies between a FF400 and a newer (faster?) RME audio interface.

I can see, in ramses RME audio interface comparison chart, that the "Converter latency in samples @44.1kHz AD/DA" is quite improved from the:
FF400 (43/28 samples)
to the
Babyface Pro FS (5/7 samples)
UCX II (5/6 samples)
802 FS (5/6 samples)
UFX III (5/6 samples)

However, this refer to AD/DA conversion and not the "internal handling" or what to call it, so I'm not sure whether this also translates to the playback speed when working only with VSTi's and such.
Therefore I'd need the help from the experts here, who understands how this work

Yes, but there are people, who cannot imagine their life without TB....

And do try throttlestop! My intel laptop runs at 3.8ghz instead of 2.8 with it which is near it's max 4ghz turbo. And at a lower vcore.
It could give you an extra 20 to 30 %, which is more then a new CPU with p e core problems.
And since you have a k processor it could do much better.

Yes and no, on a laptop like mine there is little you can do in the bios so throttlestop to the rescue. You can probably do what you need from the bios, but throttlestop makes it possible from windows and easy to experiment a little. The goal would be to have it run continuously on a as high as possible all core turbo at least when working so no throttling.  At minimum it as a good tool to see what your cpu is doing with a high daw load. At what speed the cores are running and what is the load.

Thanks, yes this is interesting!

1. I guess the FF400 is supposed to have about the same values as the FF800 in the list? (same latency afaik?)

2. Is this list representative for also the internal handling of audio, with other words for only VSTi's / VST FX played in the DAW? Or is AD/DA conversion somehow involved in this?

They're identical.

When you only use your output, only DA is involved.

@Ramses: FYI: The UFX+ with Thunderbolt is a bit faster only on Windows, on Mac it's the same as USB. And because the UFX3 has no Thunderbolt, you may say that the UFX 3 is a bit faster on USB.

I see. So, according to the info in "RME-FW-USB-TB-interface-vergleich-2023-06-17.xlsx", the FF400 have a DA converter latency of 28 samples @ 44.1kHz.

I'm not sure if my formula and calculations are correct, but 28 divided by 44,1 is 0,635 ms.

At the same time, looking at the lowest latency DA numbers for RME audio interfaces, which the UCX II, 802 FS and UFX III have (6 sampples @ 44,1 kHz), I get the following numbers: 6 / 44,1 = 0,136 ms.

None of them reach even one 1 ms, which then begs the question, will one notice the difference at all?

However, what I really don't understand is what the difference actually is between these products, for example FF400 vs. UCX II or UFX III, in this regard, since the buffer size can be chosen in the settings.

With other words, both all these audio interfaces would have the same latency with for example a buffer size of 128 according to the calculations? So what makes one audio interface then faster (with less latency) than the other? Am I missing a key component in my calculations? I probably am...

This is exactly what I'm trying to understand. Since (and also as mentioned before) these audio interfaces are not audio accelerators like for example 3D GeForce graphic cards are for 3D content/games.

Which then begs the question, could I get a noticeably lower latency (lowest possible buffer setting without dropouts, clicks and pops) with a UCX II or UFX III compared to my FF400 which I run via a Firewire PCIe card (since I don't have a built in FW interface in the motherboard)?

And it seems the answer is actually: no, I can not. At least not for only DA conversion, (only playback from DAW). There's no RTL latency involved there AFAIK, and I'm not even routing anything in TotalMix so no RTL from that either I suppose.

Noticeably, probably not. But, it depends on many things. If you change computer, it may behave better or worse. Comparing one interface running on one computer and another interface on second computer is simply tricky and hard to guess in advance.

But in your case, you need mainly stronger computer for your projects, or optimize your current projects. Newer interface might also help, but I would first get stronger computer.

Also, I would avoid big-little, or verify, that your DAW and plugins work fine on big-little.