New Ryzens and DAWBench.

[Mikelo]

Yes, absolutely. I was hoping to have this finished earlier in the week and specs already updated, but things didn't go as smoothly as I hoped. I'm not 100% happy with the tuf board, the DPC is higher than I prefer and whilst it got me through testing I'm not overly keen to start plugging in tons of extra hardware into it.

So, next week I'm doing some board testing and then will update the spec to reflect it. Given the results I plan to do a few different models, they are clearly going to be popular for a while!

Awesome Stuff!!!

[Liero]

Yes, absolutely. I was hoping to have this finished earlier in the week and specs already updated, but things didn't go as smoothly as I hoped. I'm not 100% happy with the tuf board, the DPC is higher than I prefer and whilst it got me through testing I'm not overly keen to start plugging in tons of extra hardware into it.

So, next week I'm doing some board testing and then will update the spec to reflect it. Given the results I plan to do a few different models, they are clearly going to be popular for a while!

It would be interesting to do a custom VST performance test that is more focused on a small number of tracks with high CPU plugins. The problem with using SGA1566 is that even in hq mode it's very cpu light compared to something like UVI Plate in insane quality mode, Soothe EQ, Massive X -- so the test scales across cores and tracks much better than potentially other setups.

Especially the 12-core 3900x would be interesting to test with less tracks and more cpu demand, with its dual-die configuration and infinity fabric interconnect.

[legendCNCD]

Yes, absolutely. I was hoping to have this finished earlier in the week and specs already updated, but things didn't go as smoothly as I hoped. I'm not 100% happy with the tuf board, the DPC is higher than I prefer and whilst it got me through testing I'm not overly keen to start plugging in tons of extra hardware into it.

So, next week I'm doing some board testing and then will update the spec to reflect it. Given the results I plan to do a few different models, they are clearly going to be popular for a while!

It would be interesting to do a custom VST performance test that is more focused on a small number of tracks with high CPU plugins. The problem with using SGA1566 is that even in hq mode it's very cpu light compared to something like UVI Plate in insane quality mode, Soothe EQ, Massive X -- so the test scales across cores and tracks much better than potentially other setups.

Especially the 12-core 3900x would be interesting to test with less tracks and more cpu demand, with its dual-die configuration and infinity fabric interconnect.

Few Divas, Omnispheres, Soothes, BX SSL G Channels, ColorCopys, ValhallaRooms, nVelopes, Karakters, Omega 458a's... Yeah, a varied mix would be a nice but might be impossible in the end.

[Liero]

It wouldn't really matter exactly with which plugins you do it.

The actual thing to be tested would be a scenario, where one core alone is not enough processing power to process the plugins of one track. In the SGA1156 test this isn't even close to being the case, so the processor is really never put into this difficult situation that would reveal possible weaknesses in core-to-core communication.

If you're wondering what the real-world example would be of when this is happening - at least it happens to Bitwig users all the time because of the nested/layered way you can load stuff onto just one track. You can easily and handily have a multi-mic drumkit set up with bleeds on just one track.

It also happens very often to me when using UVI Plate, which IMO has the most incredible sounding reverb when you put it into insane quality mode, which unfortunately makes my cpu jump up from 0% to 80%. Not much headroom for other plugins on the same track after that.

[Scotty]

Kaine, just a big thanks for your generosity in sharing the information. Your posts are shared across several Facebook groups to which I belong. There is no one else out there giving us the quality information that we need to make these decisions specific to the audio production universe.

[Scotty]

It would be interesting to do a custom VST performance test that is more focused on a small number of tracks with high CPU plugins. The problem with using SGA1566 is that even in hq mode it's very cpu light compared to something like UVI Plate in insane quality mode, Soothe EQ, Massive X -- so the test scales across cores and tracks much better than potentially other setups.

Especially the 12-core 3900x would be interesting to test with less tracks and more cpu demand, with its dual-die configuration and infinity fabric interconnect.

Agreed, it would be great to have another plugin loading scenario as you describe to get another real world performance perspective.

[DJ Warmonger]

May update could explain random crashes I'm getting recently, pretty much every day

There is a new chipset driver released: https://www.amd.com/en/support/chipsets ... t-am4/x470

Thanks, but that didn't help

[Lesha]

How about a BIOS update?

[Kaine]

The actual thing to be tested would be a scenario, where one core alone is not enough processing power to process the plugins of one track.
>snip<
It also happens very often to me when using UVI Plate, which IMO has the most incredible sounding reverb when you put it into insane quality mode, which unfortunately makes my cpu jump up from 0% to 80%. Not much headroom for other plugins on the same track after that.

You've just outlined why mixed-mode tests are so hard to do.

If you have 20 plugins and one of them overloads a core and the other 7 cores are all still empty, but in that scenario, it all falls over... what did you just prove?

[Liero]

The actual thing to be tested would be a scenario, where one core alone is not enough processing power to process the plugins of one track.
>snip<
It also happens very often to me when using UVI Plate, which IMO has the most incredible sounding reverb when you put it into insane quality mode, which unfortunately makes my cpu jump up from 0% to 80%. Not much headroom for other plugins on the same track after that.

You've just outlined why mixed-mode tests are so hard to do.

If you have 20 plugins and one of them overloads a core and the other 7 cores are all still empty, but in that scenario, it all falls over... what did you just prove?

I don't entirely understand what you're saying.

Having a test where we have, say, 10 really cpu intensive plugins on one track and duplicate that track for the test instead of the lightweight SGA1156 ones, you might see very different results from different processors because the core interconnects are taxed more in the former scenario. Small buffer sizes might also start having a bigger negative impact, especially on processors like the 3900X/3950X.

[zircon]

Why would core interconnects be taxed more in that case? 10x plugins on one core vs 100x plugins on one core...?

[Liero]

Why would core interconnects be taxed more in that case? 10x plugins on one core vs 100x plugins on one core...?

Because processes are (most of the time and depending on the plugin) threaded strictly per track.

To put it slightly simplified:
One track that has plugin A, B and C on it won't process plugin A on core 1, plugin B on core 2 and plugin C on core 3. If it did, a slight latency would be created as data would have to be moved from one core to another. Instead, all the plugins are processed by the same core. Only when another, separate track is created, can the processor allocate a new core for the job, as the data it's having to process isn't dependent on any other processes.

Now, when plugin A, B and C _cannot_ be processed by core 1 alone, because the workload is too heavy, the processing has to be partly offloaded to another core, and this is where the interconnects get taxed, and some processors are worse at this than others. The 3900X that has a dual chiplet design in particular is probably bad at this, when the data needs to be moved from one chiplet to the other.

So when DAWbench tests with a few light plugins per track only, it creates a very optimal situation for the processor, as it allows processing to be threaded and scaled very easily. This doesn't always represent real-world scenarios very well, especially in DAW's like Bitwig, that have potentially many levels of nesting on one track -- meaning that very much processing has to be done on basically one thread.

[Liero]

Here's a stab at what the whole thing would be like in the world of humans:

Imagine you're working in the 1700's without calculators and your job is to solve mathematical equations in a very fixed timeframe for Math Corp. Ltd. You have a set time allocated for every equation, and if you can't make it in time something horrible happens, your boss gets very angry (this would be the audio dropout in our world).

Now imagine that you're getting a low amount of easy equations from the boss. No problem, you have enough time to do the equations yourself, you don't need any help. Everyone is happy.
Now imagine you suddenly get a huge amount of equations but you have to solve them in the same short time. You have an assistant you can use to help you in these situations (that would be the other cores in the processor), but to get the paper with the equations that you need help with to your assistant, you need to run all the way across the street to another building. Running all that way takes time, making it more likely to be even more late, making the boss angry. You running across the street to your assistant with the equations is the processor interconnect. Some processors have long streets. In some you have 3 assistants with you in the same room, and 4 more across the street a long way away.

Only way to test how well you and your assistants get the job done is to overload your workload. What dawbench is doing is basically distributing all the equations neatly and evenly straight to you and your assistants -- which is great, of course, but isn't always what happens in real workloads.

[DoktorTenma]

What you are missing in your scenario is that your assistant/s can't do their calculations until you have finished your calculations as their calculations are based on yours.

For example, on a track you have the following chain: synth->delay->reverb->compressor

The delay can't calculate its results until it has got the calculated results from the synth.
The reverb can't calculate its results until it has got the calculated results from the delay.
And the compressor can't calculate its result until it has got the calculated results from the reverb.

This is the reason that a track is using one core, because it does not make sense to split these calculations across cores as a core then has to access the calculated results from another core, which depending on the cpu design is more or less efficient. By having one core do all these calculations the results are as close as possible to the core already.

If you have a session where one track is overloading a core of your cpu, you need to either print that track so it doesn't need to be calculated in real time, overclock your cpu so that each core gains some additional clock cycles to do their calculations, or get a new cpu where each core is faster for your use case than the cpu you are currently using. Buying a cpu with more cores but where each core can process the same amount of calculations as your current cpu will not help you in this case.

Now, if your problem is that you have say 30 tracks in your session and you get problems when you add another track, and each track uses on average 10% of a core, then getting a cpu as fast or faster with additional cores will help you add more tracks to your session.

With the above in mind, also remember that every plugin you put on the master bus can't be calculated until all your tracks that go to the master bus have been calculated. So if the plugins on your master bus uses 40% of a core, then in the best case you can only use 60% of each core on your cpu before you start having problems.

[Liero]

What you are missing in your scenario is that your assistant/s can't do their calculations until you have finished your calculations as their calculations are based on yours.

For example, on a track you have the following chain: synth->delay->reverb->compressor

The delay can't calculate its results until it has got the calculated results from the synth.
The reverb can't calculate its results until it has got the calculated results from the delay.
And the compressor can't calculate its result until it has got the calculated results from the reverb.

This is the reason that a track is using one core, because it does not make sense to split these calculations across cores as a core then has to access the calculated results from another core, which depending on the cpu design is more or less efficient. By having one core do all these calculations the results are as close as possible to the core already.

If you have a session where one track is overloading a core of your cpu, you need to either print that track so it doesn't need to be calculated in real time, overclock your cpu so that each core gains some additional clock cycles to do their calculations, or get a new cpu where each core is faster for your use case than the cpu you are currently using. Buying a cpu with more cores but where each core can process the same amount of calculations as your current cpu will not help you in this case.

Now, if your problem is that you have say 30 tracks in your session and you get problems when you add another track, and each track uses on average 10% of a core, then getting a cpu as fast or faster with additional cores will help you add more tracks to your session.

With the above in mind, also remember that every plugin you put on the master bus can't be calculated until all your tracks that go to the master bus have been calculated. So if the plugins on your master bus uses 40% of a core, then in the best case you can only use 60% of each core on your cpu before you start having problems.

That's exactly right, and I hoped it was implied in my simplified post to some extent, but thanks for the addition