Ryzen Memory testing for audio, does it make an impact?

Today we take another look at the Ryzen chipset and discuss further optimization’s. Memory is always a question that comes up and historically it hasn’t really had an impact for audio, where the bottleneck in performance often ends up being elsewhere in the setup.

Even with the previous generations on Ryzen where the optimal memory advised were around the 2666MHz (first generation) – 3200MHz (second generation) clock speeds and in our own testing moving up from 2666MHz to 3200MHz on either generation didn’t get us any favourable results in audio benchmarking, although it did help for video rendering workloads.

As such, I went with the previous suggested the best memory when testing around launch and AMD has publically outlined that the optimum speed is now 3733MHz with a CAS16 timing as this puts the memory on a perfect 1:1 ratio with the internal Infinity Fabric bus arrangement.

At this point 3733MHz RAM is still not overly common, even more, uncommon is the super low CAS 16 kits. I’ve currently got a 3733MHz pack being shipped to me (although only CAS17) for further testing when it arrives, although I’ll keep that for when I do a full retest in the coming week.

The results I have today is more of a comparison to show some basic gains and at a slightly cheaper price point. Above 3600MHz memory carries a sizable price premium and some of you may be wondering what gains can be achieved at what price points.

To do this testing I’ve got results generated using the 3200 RAM used in the previous testing, 3600 RAM with CAS18 which are the standard packs we use here and then I’ve run the same 3600MHz RAM clocked up to 3733MHz, which in real-terms ended up being around 3725MHz running in Windows.

3900X on X570 memory testing
3900X on X570 – Memory Speed Comparisons – DAWBench DSP Test. (click to expand)
Stock CPU
3200MHz RAM
Stock CPU
3600MHz RAM
Stock CPU
3725MHz RAM
64113115116
128118123124
256120124126
512121130131

The DAWBench DSP test gave us some small gains on the 64 buffer and then became much more apparent at larger buffer sizes, where we’re talking closer to 8% at the 512 buffer.

3900X on X570 – Memory Speed Comparisons – DAWBench Vi Test. (click to expand)
Stock
CPU
3200
RAM
CPU
Over
load
Point
Stock
CPU
3600
RAM
CPU
Over
load
Point
Stock
CPU
3725
RAM
CPU
Over
load
Point
6448070%50070%56075%
128168090%174090%206095%
2562860100%2920100%3240100%
5124020100%4060100%4520100%

What we can see here is similar small gains moving from 3200MHz to 3600MHz, with it being fairly marginal overall moving up at this level.

Clocking the RAM up towards it’s advised 3733MHz clocks in this instance produced us more notable gains with excess to 10% being seen at most buffer sizes. I’ll also note that that between the 3600MHz and 3725MHz results the memory hole started to disappear as the CPU overload point moved upwards. I suspect and remain hopeful when we see perfectly matched 3733MHz RAM with CAS 16 timings as they’ve advised, that we’ll finally see that performance hole disappear for good.

Given that 3600MHz RAM is only about 10% more costly than 3200MHz then that’s a no brainer of an upgrade, but the jump above that to 3733MHz can easily cost twice as much again depending on the quantity and size of RAM sticks that you need.

I’d expect memory costs to continue to drop over the coming months as no doubt many firms will now be ramping up 3733MHz production over the coming months. Our own provider was also on the back foot, having already killed off their 3733MHz supplies due to a lack of customer interest before the AMD launch, it’s only now that they are rapidly bringing back old lines and looking to flesh out their ranges to support the popular new platform.

In regards to overclocking the advice that AMD put forward early on appears to be very true with faster memory installed. In initial testing, I overclocked the systems and ran 3200MHz memory and saw some solid gains. With the faster memory, we see the same if not better gains and we can also run the CPU cooler at stock.

I did note that I had both an overclocked chip up and running with 3600MHz RAM and the memory performance hole pretty much disappeared completely, but the system wasn’t stable under heavy loads an there is no way you would want to run that in a production environment.

Indeed, it seems that overclocking is more or less impossible when taking the memory over 3200MHz at this time, although given the performance boost we see with the faster RAM this isn’t a complaint. This might even improve in the future as the BIOSes get optimized and better high-speed memory continues to arrive, but it’s very much something to be aware of if buying a machine at this point in the lifecycle.

One thing that the results have left me wondering, especially with the closing of the gap as we approach the 3733MHz optimum is has this always been the case. 3733MHz didn’t exist when Ryzen generation 1 arrived and I’m not even sure if it was a widely available product when Ryzen 2 launched. Even now it carries a rather hefty cost premium and I have to ponder is this simply a case of the memory market catching up to the Ryzen chipset.. has Ryzen so far simply been ahead of its time?

The last bit of testing I’m going to carry out over the coming week is to retest with the information that we’ve picked up since the first look. It’ll now be running stock clocks with the 3733MHz RAM that is shipping to us now and it’ll be running a none hybrid test version that of a freshly expanded test setup.

Scan 3XS Audio Systems

AMD 3 Series – ASIOGuard and AMD, a Further Cubase & Reaper Comparison.

In light of recent testing on the new AMD platform, a number of questions arose and I’m going to spend some time working through those over a couple of follow up articles.

The first one to tackle is Cubase which I ended up pulling from the testing this time due to uncertainty on the results being returned. This was to be the first time using Cubase 10 in the benchmarks, a change I was keen to move up to in light of them making adjustments to the engine to resolve the MMCSS issues that crept in on the previous build due to low-level OS changes. We had been working with a tweaked registry workaround in C9.5, so we were rather keen to see what other gains were to be had in working with the latest iteration of the software.

Whilst I’m looking at this I also want to start off by tackling another question in the process, namely the one of ASIOGuard.

ASIOGuard is there to stop dropouts and overloading whilst recording, it’s essentially another buffer designed to keep you safe from digital gremlins. where It also means that your trading off some degree of performance overhead in order to achieve that extra stability.

Normally, we will test with ASIOGuard disabled essentially because we’re looking to test the hardware and not ASIOGuard itself. The first result I want to post is a Cubase 10 with ASIOGuard Off/Low/Normal/High and at various buffer setting.

Cubase ASIOGuard Testing On The 3900X – Click To Expand

Firstly you’ll note that ASIOGuard off is far better performing, although I’ll note this still isn’t quite as I would have expected.

AG
Off
CPU
Over
load
Point
AG
On
Low
CPU
Over
load
Point
AG
On
Norm
CPU
Over
load
Point
AG
On
High
CPU
Over
load
Point
512272090%56035%116070%118085%
256124080%52035%60070%108080%
12886075%50035%48070%56080%
6444060%48025%40025%44075%

So, as it shows above, ASIOGuard rather skews the performance for us in testing. You can note that with a CPU overload point of roughly 90% maximum the ASIOGuard off setting gave us both the highest total polyphony and succeeded in leveraging the most amount CPU in that test.

Now with ASIOGuard on this isn’t the whole story. At each buffer setting the total performance was still there above the points where I drew the line. However, I couldn’t cleanly push past the points that I’ve indicated.

What do I mean by this?

With DAWBench testing, the way we take the metric is to simply keep adding more and more instances of whichever plugin it might be until such point where the audio overloads and then we pull back slightly and take the measurement.

What I was seeing here was the audio breaking up and then not coming back until I reduced the active channels back to the point that I’ve recorded.

So, for example, the chart above shows ASIOGuard – Low overloading on the 512 buffer at 560 notes. If I keep adding more instances until the point it crackles and falls over, it’s more like 1100 poly with 95% CPU.

So, why are the results on paper looking so low?

Because whilst I can build up to 1100 instances I then can not start/stop cleanly without it replicating the audio cut out and recover issue I note above.

So, say I take it to 1000 note poly and the audio is playing away fine. If I stop the project at this point the audio will stop playing. If I then proceed to start Cubase playing again it will immediately lock up, refusing to start playing audio again until I reduce it back to the point that I’ve noted on the chart.

Essentially it’s behaving as if it’s overloading and choking, which doesn’t make for a smooth session when recording.

So, the next question that comes to mind, is this an inherent issue inside of the Cubase 10 engine?

Cubase 10 DAWBench Vi Test On Intel 9900K – Click To Expand

Above we see the same set of ASIOGuard On/Off tests running on a 9900K at 4,9GHz all core and running 2666MHz RAM.

AG
Off
CPUOver
load
Point
AG
On
Low
CPUOver
load
Point
AG
On
Norm
CPUOver
load
Point
AG
On
High
CPUOver
load
Point
51212801001080100%60070%1180100%
25610401001000100%52060%1000100%
12872010048060%48055%56075%
6444090%44055%44050%44065%

The first thing to note is that the ASIOGuard “off” setting does look to offer us the sort of result curve that we would be expecting to see in this testing situation and with a minimum of 90% CPU being leveraged rising quickly to 100% it’s performing as we would hope to see.

The ASIOGuard itself is designed to sit as a safety buffer and at tighter settings you can see where it fails to keep up as the CPU overloads at lower buffer settings, but when working ideally it will tend to trade off performance for stability at lower ASIO buffers as well as allowing for potentially a little more overhead to be extracted at more relaxed settings.

But that aside, the results above should indicate why we prefer to run any testing in Cubase with ASIOGuard itself disabled due to more balanced results as we’re testing just the hardware and not the ASIOGuard itself.

What was also apparent was that I wasn’t seeing the “rubber banding” effect on the Intel system and that the point where it fell over, it did pretty much fall over at its audio load break-up point.

There was none of this being able to push it 200% past it’s highest start/stop result and on the Intel testing it would prove to be that the point where it started to crackle that was also the same point where it would fail the stop/start part of the test.

So, on the Intel setup, these were the respective results for Cubase and Reaper testing where the performance curves look to be as we’d expect in regards to the point of audio drop out in each instance.

Intel 9900K Test

9900K TestCubase
(AG Off)
CPU Over
load Point
Reaper CPU Over
load Point
5122720100%3400100%
2561020100%2660100%
128720100%1680100%
6444090%720100%

AMD 3900X Test

3900X TestCubase
(AG Off)
CPU Over
load Point
Reaper CPU Over
load Point
512272090%4320100%
256124080%3780100%
12886065%2120100%
6444050%112080%

So, the reason I ultimately dropped Cubase from this round was the above. I just wasn’t sure at the time what or why the results were skewed in the fashion that they were and wanted to go with a test that I considered to be less aggressive with trying to optimize its own handling.

To note, I did a similar shoot off on Ryzen 1 & 2 setups but wasn’t able to close the gap in any meaningful way although I was using an older build of the sequencer engine at the time it should be noted that I’m seeing the memory hole tighten up slightly with faster RAM than the 3200MHz which was recommended on the last generation, but is now being eschewed in AMD recommendations in place of the newer 3733MHz packs which they’ve now noted is the optimum clocking speed for working with Ryzen.

I can’t help but wonder if this was always the case and it was simply the prohibitory high price of 3600MHz+ RAM two years ago (3800MHz is still rather high cost at the time of writing), is this a case of Infinity Fabric making it to market a number of years before the supporting hardware was widely available to the general public?

At the moment the Vi test is being updated, so I’ll look to do a pure VI test in the coming days and will republish with updated results as well as delving further into the memory handling side. I’ll note that the performance curve that I saw in testing this time mirrored my first run with the hybrid test build, but I’m also keen to see how it plays out doing a full retest with it across the board.

To draw this article to a close, Cubase 10 on the Intel side appears to be behaving as expected but the AMD handling has proven erratic enough for me to question it in regards to giving the hardware being examined a fairer test. For Cubase users and importantly for those of you working with large sample libraries, this raises questions on the suitability of AMD for handling your workload.

For the rest of us, it raises the question on whether or not its Cubase or Reaper that is the exception to the rule here and right now I’m not well placed to answer it. I understand there are further builds in the pipeline, so more testing will be carried out there as and when it’s ported.

Ryzen 3000 Series CPU Testing

All 3XS Computer Systems At Scan

AMD Ryzen 3600, 3700X & 3900X DaWBench tested – 3 is it the magic number?

*Please note, further testing is currently ongoing due to new test builds being made available and due to community feedback requesting a few different usage scenarios. Some interesting results are being seen, updates will be posted in detail over the coming week.*

First follow up test – ASIOGuard and AMD

The AMD Ryzen 3000 series has been well anticipated and in fact the last time there was this much buzz around a release, it was quite possibly the first Ryzen generation a couple of years back. At that time we saw the platform pull AMD back into the limelight and whilst the results were mixed across many usage scenarios, it was clear the platform certainly had the potential to live up to.

In the interim we’ve of course had the 2000 series, which built upon the gains we’d already seen and continued to close the gap even further. AMD, of course, has continued tweaking the platform throughout this period, acknowledging some of the internal latency issues we also saw in the first round of testing and generally showing positive improvements along the way.

I’m coming to this with a short delay after launch due to a shortage of hardware over the first week. The mainstream reviewers looked to have got their hands on them in the week prior to launch, so there is already a lot of coverage out there regarding the more common applications and the hardware has performed well. The upside of this is that I only managed to put one of the chips across the bench before the launch day AGESA BIOS update surfaced which after applying I also saw a small improvement to performance and so ensured that all testing was done with this in place.

I’m going to be putting the 3600, 3700X & 3900X through their paces here and as normal I’ll be looking to max turbo clock them where I can. This ensures we don’t have a slowest core scenario tipping things into overloading earlier than necessary, but it does mean that on a stock setup you should allow for some variance.

The 3600 for a none X series chip did well, allowing us to take it to a steady 4.2GHz on all of it’s 6 dual threaded cores. The 3700X allowed us to max out all of 8 of its cores at 4.4GHz, and the 3900X managed 4.3GHz whilst sitting around 70 degrees even under maximum load. I managed a 4.4Ghz but not without seeing a huge increase in temperatures alongside it.

Whilst the promotional headlines have been focused on the 7nm die shrink, it should be noted that the entire architecture has received an overhaul in the process with AMD noting a sizable 15% increase in IPC performance. Other notable improvements include further tuning to the internal memory latencies and a sizable increase to the L3 cache, both of which should be beneficial to our performance scores.

For the Ryzen testing, I’m using the X570 Asus Tuf board which was the first of the new range to land in the office. It has been fully updated prior to testing with the latest BIOS and running 3200MHz Corsair LPX memory


With news over the past 12 months of security concerns and various performance affecting patches that have since followed, I’ve set up a new test bench where the Windows 10 build being used is the current 1903 with all drivers being freshly installed. Also given all these changes I’ve benched a number of the Intel chips in this round of testing, with both of the Z390 and X299 boards being fully updated Asus Prime boards.

On top of that reinstall and due to exceeding the benchmarking overhead in the last round with the largest available chips, I’ve made a few modifications to the standard DAWBench tests this time as I suspect that I run the risk of easily surpassing the tests in their default forms.

With the DAWBench DSP test, the SGA1566 plugin now has all instances set to the high-performance setting, running at 24/48 and this gives us plenty of headroom for our needs.

The Kontakt based DAWBench VI test, on the other hand, I would expect to quite quickly outperform with the CPU’s we have here.

I’ve attempted to soak up some of the available performance we have on offer by applying two instances of the SGA1566 plugin in high-performance mode to each of the 16 hidden sine tracks, which on my 9900K testbed took up about 50% of the available performance. This should give us a reasonable baseline to start from and still have the ability to check for any performance affected by latency.

Since the Native KA6 interface has had a generational jump and the older model is now discontinued, I’ve now gone and retired the old testing interface. I’ve now switched it up to an RME Babyface on this round of testing and shall be sticking with that going forward.

Another change is that both sets of tests are being reported using Reaper this time. I completed the testing initially using both Reaper and Cubase, but upon looking over the results I saw an irregularity that sent me back to retest again using Reaper for both sets, more of which I shall cover in the results section.

Having made all those changes, please be aware that these results and prior results are in no way comparable. I’ve changed the following and have retested all CPU’s listed in the results.

OS version.
BIOS versions.
Reaper version.
Cubase removed.
Different audio interface.
Modified DAWBench versions.

The one benchmark that can still be used to loosely compare is CPU-Z and that is where we shall start.

AMD 3600 clocked to 4.2GHz
AMD 3700X clocked to 4.3GHz
AMD 3900X clocked to 4.4GHz
3600 @ 4.2GHz – CPU-Z Bench Test
3700X @ 4.4GHz – CPU-Z Bench Test
3700X @ 4.3GHz – CPU-Z Bench Test

I’ve used the inbuilt 9900K metric as a baseline comparison. I’ll note that the result they have recorded is within 10% of my last round of testing, so it seems quite fitting to use it here.

So first up DAWBench wise is the classic DSP test, running the SGA1566 variant as covered up top.

Dawbench-DSP-Chart-2019Q3-1
Dawbench DSP – Click To Expand

This test sees us stacking up plugin instances on a thread by thread by thread basis until the whole CPU hits a breaking point. An impressive result from the sub £200 AMD and the top end 3900X is trading blows with the £1000+ Intel chips. This test is our raw performance test and as hoped the results are impressive.

The second chart we have is the DAWBench VI Kontakt test, which I imagine is going to be the interesting one for most readers following on from prior writes ups.

DAWBench Vi Test – Click To Expand

And interesting it certainly was. The cross core latency we’ve seen in earlier models has gone on the 3600 and we were hitting 95% on the 64 buffer on the 3700X with 100% leveraged on the 128 buffer, both of which are certainly welcome sights.

The 3900X with its new dual chiplet design was the only model to not come away with a clean sheet, although given we have an extra die section to deal with, this might not prove to be a huge surprise. I would expect it to mature in much the same fashion as the other chips below it in the range have done over future iterations and no doubt looking forward to them fine-tuning this new design further.

With the first round of testing as noted up top, I used Cubase 10 initially for the DAWBench VI testing and everything looked great right up until the final test. On the 3900X I saw a 30% performance drop at 64 buffer with only 70% of the CPU being used at maximum load and 128 gave me 80% – 90% with the full CPU being leveraged at the 256 buffer and above mirroring the low buffer latency we’ve seen in previous generations.

It’s at this point where I wondered if we’d see any difference with a sequencer switch out, it didn’t help in the previous testing, but C10 had a few major changes under the hood over earlier versions and I’m keen to see if any of those have impacted here. I rebuilt the new test in Reaper and took another look at it with Reaper offering differing results. I still saw a performance hole at the 64 and 128 buffers, but this time it was more like 80% (64 buffer) and 90% (128 buffer) of the CPU being leveraged before it started to top out.

So, interesting to note variance drift between sequencers and how efficiently Kontakt appears to be running within them. I did upon seeing this completely re-bench in Reaper and those are the results presented. but do be aware of the sequencer variance that appears to be in play.

It’s also worth noting that some sequencer may not be able to address the full 32 threads efficiently, even if it can currently see them. I can foresee a lot of optimization being required by various DAW coders in order to ensure that their software can still keep up with the new hardware that is currently emerging.

So, overall thoughts are one of being largely impressed at each given price point. I don’t think I’d drop as low as the 3600 personally, but the 3700X has a strong claim as a superb all-rounder at the entry level and both of these chips seem to have largely shaken any concerns that remain about internal latency handling.

The 3900X has the noted performance latency still, although it seems to vary between applications and we don’t see that occurring with either the Reaper or Cubase test on the Intel side. I wouldn’t normally be happy with seeing anything drop out at 70% or 80% load but there is certainly an argument that it still offers reasonable value as even then it exceeds the 9900K which is currently sat around the same price.

Certainly, anyone working above a 128 buffer has little to no concern there as it appears to recover in full by the 256 buffer.

So there we have it, a great first outing for AMD’s 7nm design. I’ve seen comments aplenty about the lack of overclocking capabilities and yes we’ve come up short of the all core clock that I was aiming for in two of the tests, but I do kind of expect that from any first generation chip after a die shrink. I’ve certainly no doubt that we’ll have refinements over the next couple of years that will successfully extract every last bit of performance from the Zen 2 platform.

My only reservation at this time is compatibility with third-party hardware and mainly interfaces. We saw some compatibility issues with Ryzen 1 & 2 with some PCIe sound cards and some USB based interfaces. ASMedia have a bit of a poor rep on Intel board where they’ve provided their third party USB3 solutions as audio devices don’t tend to play too well on them. We saw similar incidents with the implementation they packaged for the Ryzen board on generation one and thankfully it was less common on Ryzen gen 2.

Ryzen Gen 3 has an AMD designed USB implementation but built around an ASMedia package and at this point, I’ve little idea how it will hold up with all the device we have available. I was testing using a Babyface Pro this time around, so that’s validated, but I would certainly check with user groups for your key devices for any compatibility issues prior to buying.

Looking forward, unsurprisingly Intel’s next refresh details have started to leak across various sites. The Cometlake refresh has a 10 core chip and various price reductions being dangled via those leaks, which obviously look to challenge this Ryzen release when they arrive.

Whilst some people might already be rolling their eyes at this leak timing, those who remember back to the last time we were entrenched in some good ole CPU wars, they’ll remember that this is pretty much business as usual and I can see price wars on the horizon as AMD snatches more and more market share.

But that’s all still to come in the future. Right now, for the time being, the third iteration AMD Ryzen series is easily their most compelling offering yet.

3XS Audio Production System @ Scan