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.

A Recording Interface is not an Audio Accelerator, and even companies like UAD have their own challenges with DSP power in this regard, limiting the number of plugins that can be used. The problem with audio processing is that it needs to be done in real-time; you can't buffer it at will. The more and the more CPU-intensive VSTi and VST plugins you use, the more computational power your computer needs to process the data in a timely manner.

That's why, in a project, you may need to increase the ASIO buffer size (or use different buffers on Apple devices) to give your computer enough time to calculate audio data and perform I/O, or else you may experience audio dropouts. Additionally, Windows and macOS operating systems were not originally designed for real-time tasks. While they can now handle many tasks "within their capabilities" quickly, there are no guarantees about when these tasks will be executed.

Adding to the challenge, low-level routines (drivers) on CPUs are generally given priority to ensure data integrity in non-real-time operating systems. A running driver cannot be interrupted by the process scheduler; driver code can only interrupt itself and release a CPU core for other tasks. This works to varying degrees depending on how well the CPU is suited for the task (Single Core vs. Multi-Core Performance) and the quality of the drivers (DPC Latency). In the worst case, even the fastest computer can be slowed down by poor drivers, making it unsuitable for real-time audio processing.

This is just the hardware side of the issue. There's just as much that can go wrong in the realm of application software:
1. poorly written DAW software
2. CPU-hungry VSTi/VST plugins
3. poor or inefficient project organization, and
4. how well a DAW can utilize multiple CPU cores.

Regarding these points:

to 1. For poorly written DAW software, I would recommend sticking to established products from reputable manufacturers.

to 2. In the case of CPU-intensive VST and VSTi plugins, research which ones exceed the usual performance requirements or latency expectations. You should either avoid them or consider freezing tracks by precomputing audio data and saving it as a WAV file, so your DAW doesn't have to repeatedly calculate it in real-time. DAWs like Cubase offer extensive features for working with frozen tracks.

to 3. Project organization is critical. If you use many inserts on a track, they will be processed serially one after the other by a CPU thread. If these VST plugins are also CPU-hungry with high latency, it can significantly add to the required CPU time. CPUs with a high core count but low single-thread performance can struggle to calculate data in time.

to 4. Pay attention to how well your DAW can distribute the workload across CPU cores/threads. Not all DAWs are equally efficient in this regard.

When selecting a CPU, don't just focus on core count; prioritize CPUs with high single-thread performance.

Now, returning to RME, here are the key advantages for your situation:

RME recording interfaces do not rely on third-party I/O components; communication with the computer is handled through the internal FPGA chip. This chip can be reprogrammed via a flash operation. Combined with excellent drivers, this provides a solid foundation for any RME product, whether it connects to the computer via PCIe, Firewire, or USB.

While it's true that an interface with fewer I/O ports requires less bandwidth for the transfer between the audio interface and the computer (typically, all tracks are transmitted, whether in use or not), this is usually a concern for low-quality or poorly configured PCs. Therefore, I wouldn't be deterred from purchasing a UFX III if you need its ports, features, and I/O reserves for future expansion.

This is a complex topic, and I would recommend working with a company that can provide comprehensive guidance in the following areas:

1. Choosing the right DAW product and project organization, possibly testing with a demo project.
2. Building a turnkey computer with suitable components, potentially testing with a demo project to determine which CPU handles the workload best.
3. Providing support for optimizing your DAW projects.

I hope this helps!

If you place such high demands on your DAW projects, then if I were you I would play it safe and exhaust all conceivable possibilities to optimize the projects and try out a lot.

I would put every VST and VSTi to the test and optimize it.

Have you ever frozen all tracks or made them into a simple wave file using render in place functions? Your computer, which has a much more powerful CPU than mine, should easily be able to output 150 wave files.

I would first approach and explore what causes the most performance problems in your projects and, as I said, work on your project organization and the VST/VSTi used.

With Cubase, for example, it is easily possible to freeze tracks, to temporarily release the freeze, but to keep the frozen wav file if you want to quickly switch between frozen and unfrozen.

Or you can/should use FX sends instead of multiple FX as insert in individual tracks.

I bet you still have great potential for optimization at this point, which you have not yet identified as such.

Before buying new hardware (be it a PC or recording interface), I think it would be better to optimize what you already have:

- Structure of the DAW projects
- Performance of your PC (check DPC latencies with LatencyMon and weed out bad drivers)

At the same time, try to see if the DAWs from the market leaders offer you an advantage over Cakewalk.

For example, I would counter-test with demo versions of Cubase and Reaper and, when building a large project, examine step by step at which point the performance suddenly collapses.

If you get good insights from this optimization process, you will benefit the most.

Simply investing in new, faster HW in the hope that you can solve problems simply with money doesn't always work or only works for a short time, until the next project comes along that might again exceed some performance limits.

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

A collection of URLs with tuning tips you can find here, maybe you find something additional / interesting for you:
https://forum.rme-audio.de/viewtopic.ph … 04#p186404

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

And Intel might still have more efficient working cores regarding IPC (instructions per cycle).

But tbh .. all those top CPUs are faster than mine and my system still works satisfactory ;-)

More important is to get a system with good drivers that do not block any CPU cores not to get issues in terms of DPC latencies.

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.