New Podcast Uploaded :

Now across all of the major podcasting platforms.

DAWbench Radio Show : Episode 45

Music Tech Pioneers IX : Kim Ryrie : Fairlight : CMI to MFX and Beyond !

A few links below, but easily found on most others with a search.

· Podcast Home Page : Here

· Apple Podcasts : Here

· Spotify : Here

Hosted by Vin Curigliano of AAVIM Technology, I am joined by guest co-host Pete Brown of Microsoft and special guest Kim Ryrie, who is the Co-Founder of Fairlight.

We cover Kim’s early history with music and technology , and how that lead to his early adventures in developing synthesisers and the eventual founding of Fairlight, his early pioneering days exploring revolutionary computer and music technologies that lead to the development of the CMI, which was the Worlds first commercially available sampling synthesiser and real time sequencer.

We cover the series of events and chance meetings that eventuated in the CMI ( Computer Musical Instrument) being introduced to leading recording artists and producers, that embraced the technology and catapulted the company into the mainstream of music production. We discuss the meteoric rise, the fall, and the eventual pivot away from Music Production and into Audio Post Production

We discuss the lesser known game changing innovations introduced with the MFX Multi Track Hard Disk Recording System, that was years ahead of the competition and defined Digital Audio Workstations throughout the 90’s and beyond.

We cover Kims segue into new pioneering areas of loud speaker time/phase correction technologies, the continuation of Fairlight after his departure, the revival of the CMI in a more modern take for its 30th Anniversary, and how it continues to inspire and innovate via a dedicated community, as well as fresh developments from 3rd parties.

We muse over the current state of Music Technology, sharing some great insights and hilarious behind the scenes stories, and much, much more.

Host & Guest Links :

AAVIM Technology : www.aavimt.com.au

DAWbench : www.dawbench.com

Microsoft : www.microsoft.com

Pete Brown : https://twitter.com/Pete_Brown

Kim Ryrie : https://www.linkedin.com/in/kim-ryrie-82185147/

VO :

Andrew Peters : www.andrewpetersvo.com

Music Themes :

Original DAWbench VI Theme Music composed by Rob John : Independent Music Productions :

http://www.indmusicprods.com

DAWbench Radio Show ReMix by Erin McKimm : www.erinmckimm.com

All Rights Reserved : © AAVIMT 2026

New Podcast Uploaded :

Now across all of the major podcasting platforms.

DAWbench Radio Show : Episode 44

TechBytes 12 : 2026 Music Technology Round Up : Mid Year Review !

A few links below, but easily found on most others with a search.

· Podcast Home Page : Here

· Apple Podcasts : Here

· Spotify : Here

Hosted by Vin Curigliano of AAVIM Technology , I am joined by guest co-hosts Pete Brown of Microsoft and Chris Mann of Link Audio.

We catch up again on what all of us have been up to since last show, cover the domino effecting my business due to the current RAMpocolypse, check in on Petes work on MIDI 2.0 and the inbox Windows ASIO Driver, etc

We do a general catch up and summary of the last 6 Months in DAWbench testing and development work. We discuss the details of some new VI sessions that I have developed currently in BETA, and cover some hurdles exploring alternate Sample Players.

We again cover some of the major new DAW/Sofware releases, and some cool Emerging Tech, cover the conclusion of the recent NI insolvency saga with the welcome aquisition by InMusic, and discuss how that could play out.

We discuss the emerging CPU and Platform Wars covering Apple M5 Series vs x86 vs Arm , cover how and why both Intel and AMD are rereleasing older DDR4 based tech, and discuss the official release of the Nvidia N1X Mobile/Desktop chip, now branded as RTX Spark.

We share some more stories from the Tech Support Trenches, and much more.

Host & Guest Links :

AAVIM Technology : www.aavimt.com.au

DAWbench : www.dawbench.com

Microsoft : www.microsoft.com

Pete Brown : https://twitter.com/Pete_Brown

Link Audio : www.linkaudio.com.au

VO :

Andrew Peters : www.andrewpetersvo.com

Music Themes :

Original DAWbench VI Theme Music composed by Rob John : Independent Music Productions :

http://www.indmusicprods.com

DAWbench Radio Show ReMix by Erin McKimm : www.erinmckimm.com

All Rights Reserved : © AAVIMT 2026

New Podcast Uploaded :

Now across all of the major podcasting platforms.

DAWbench Radio Show : Episode 43

Music Tech Pioneers VIII : Manfred Rürup : Steinberg : The Early Years !

A few links below, but easily found on most others with a search.

· Podcast Home Page : Here

· Apple Podcasts : Here

· Spotify : Here

Hosted by Vin Curigliano of AAVIM Technology, I am joined by guest co-host Pete Brown of Microsoft and special guest Manfred Rürup, who is the Co-Founder and Ex CEO of Steinberg.

We cover Manfred’s early history with music and technology , and how that lead to a Professional Recording and Performing Career throughout the 70’s and early 80’s, before crossing paths with Charlie Steinberg in the early 80’s, and founding Steinberg Research.

We discuss Manfred’s professional music career across multiple bands and performing artists, sharing some adventures that were encountered navigating those heady days of recording and touring during that era, cover some of the albums and music styles explored , gear used, etc, from early Prog Rock, Fusion, Experimental, to German New Wave.

We cover the early pioneering days of being one of the first to explore computer based sequencing on less than ideal computer hardware, the evolution of the sequencing packages that paved the way to the innovations that the team visualised and brought to the ground breaking and game changing release of Cubase in 1989, that became the blueprint for the way DAW workflow environments were approached and implemented across most if not all DAW’s that followed.

We discuss the landmark releases of Cubase, the initial adventures of introducing digital audio to the Cubase sequencing environment, the preliminary excursions using initially 3rd party audio hardware, then moving to the first native version on Atari Falcon, and the eventual evolution of VST ( Virtual Studio Technology ), which launched the native DAW era on Mac and Windows, and created a whole new industry around Plugins and Virtual Instruments.

We cover the development of ASIO , that although is well known to be the industry standard and essentially default low latency driver protocol for Windows, we discuss how it was orginally also available on earlier Mac OS versions pre OSX, and share some opinions and Pro’s and Cons on that not being embraced on the later platform.

We discuss the development of Nuendo and the reasoning behind the move in that direction, the eventual merging of the codebase with Cubase, and Manfreds exodus shortly after the initial Steinberg sale to Pinnacle.

We also cover Manfred’s creative and business endeavors after leaving Steinberg, muse over the current state of Music Technology, sharing some great insights and behind the scenes stories, and much, much more.

Host & Guest Links :

AAVIM Technology : www.aavimt.com.au

DAWbench : www.dawbench.com

Microsoft : www.microsoft.com

Pete Brown : https://twitter.com/Pete_Brown

Manfred Rürup : https://www.linkedin.com/in/manfred-ruerup-808250/

VO :

Andrew Peters : www.andrewpetersvo.com

Music Themes :

Original DAWbench VI Theme Music composed by Rob John : Independent Music Productions :

http://www.indmusicprods.com

DAWbench Radio Show ReMix by Erin McKimm : www.erinmckimm.com

All Rights Reserved : © AAVIMT 2026

New Podcast Uploaded :

Now across all of the major podcasting platforms.

DAWbench Radio Show : Episode 42

Music Tech Pioneers VII : Wolfgang Kundrus : Steinberg, Studio One and Beyond !

A few links below, but easily found on most others with a search.

· Podcast Home Page : Here

· Apple Podcasts : Here

· Spotify : Here

Hosted by Vin Curigliano of AAVIM Technology, I am joined by guest co-host Pete Brown of Microsoft and special guest Wolfgang Kundrus, who is one of the leading and most influential music software architects of the last 4 decades.

He was part of the team behind Steinberg Cubase and Nuendo, as well as the game changing innovations that were brought forward during that tenure.

He was also the co-founder of PreSonus Software and one of the leading developers of Studio One, and is currently the lead developer of the Opus Engine at East West.

We discuss Wolfgangs early history with music and technology , and how that lead a path to joining the team at Steinberg, the concepts and innovations that he brought to Cubase ( arrange window/toolbox, etc ) that became the blueprint for the way DAW workflow environments were approached and implemented across most if not all DAW’s that followed.

We cover the early days of introducing digital audio to the Cubase sequencing environment, the preliminary excursions using initially 3rd party audio hardware, then moving to the first native version on Atari Falcon, and the eventual evolution of VST ( Virtual Studio Technology ), which launched the native DAW era on Mac and Windows.

We discuss the development of Nuendo, the eventual merging of the codebase with Cubase SX, and the exodus after the initial Cubase sale to Pinnacle.

We also cover Wolfgang co-founding Presonus Software and being a lead developer of Studio One, his move to East West to lead the Opus Engine Development, his recent adventures with AI coding, sharing some great insights and behind the scenes stories, and much, much more.

Host & Guest Links :

AAVIM Technology : www.aavimt.com.au

DAWbench : www.dawbench.com

Microsoft : www.microsoft.com

Pete Brown : https://twitter.com/Pete_Brown

Wolfgang Kundrus : https://www.linkedin.com/in/wkundrus/

East West : https://www.soundsonline.com/

VO :

Andrew Peters : www.andrewpetersvo.com

Music Themes :

Original DAWbench VI Theme Music composed by Rob John : Independent Music Productions :

http://www.indmusicprods.com

DAWbench Radio Show ReMix by Erin McKimm : www.erinmckimm.com

All Rights Reserved : © AAVIMT 2026

Over the course of testing and reporting on audio interface LLP across the last 15+ years, I have at various times navigated driver development from respective manufacturers where updated drivers were not necessarily moving in the right direction. The reasoning’s and extent would vary, and in most cases would be acknowledged if pointed out, and addressed.

In some instances there would be some slight variations and/or hurdles where performance would drop off unexpectedly at various latency over others, or even overall performance would move backwards to varying degree’s. Also, of course, driver development which showed welcome measurable improvements, with varying degrees of everything in between also navigated.

Developing, Maintaining, Improving !

Manufacturers who develop their own Controllers/Firmware and Software/ Drivers inhouse have more easily maintained a consistency over the years across the protocols they have full control of, while others who rely in varying degrees on 3^rd party controllers/drivers can at times be navigating dependencies in less than ideal environments.

Many if not most fall into the 2^nd category , which I detailed in Part 1 of this series of articles, relying on 3^rd party controllers and 3^rd party OEM drivers, which can work out O.K, for the most part, but will be harder to address when things go sideways, even severe cases the loss of the 3^rd party component. This has happened numerous times over the years, DICE FW controller/driver being one example, and even more recently Audionate discontinued their dedicated Brooklyn II controller chip, which is now licensed for other developers to utilise in their respective FPGA’s. In some instances previous performance has not been maintained.

In short, sometimes updated drivers do not guarantee better performance. Lots of variables from changes in controllers/firmware/driver genealogy, and even available resources and personal can all play a part.

This brings me to the focus of this article, where I will detail revisiting some recently tested interfaces with updated drivers, which I do at various times with my large inhouse interface pool to see if the pins have moved substantially, one way or the other across numerous interfaces.

I’ll highlight 2 well known and established manufacturers interfaces at the extreme ends of the spectrum, one delivering a welcome and measurable performance improvement, the other, well…, read on.

MOTU M2 – Revisted !

Results for original driver v latest !

My initial testing for the MOTU M2 driver placed it around mid pack amongst the better USB interfaces tested, and I was pleasantly surprised and initially impressed after having very mixed results with MOTU drivers over previous years, across multiple generational families of interfaces.

The team at MOTU have obviously been putting in some work fine tuning the drivers since my first visit, as the current driver out performs all other USB interface tested except for the RME UFX + USB3 unit, which is impressive to say the least.

MOTU have delivered performance on their USB2 interfaces that is on par with RME !

It also places the unit firmly in the All Time Top 20 , now positioned at 12 .

I haven’t had the opportunity to test their TB/USB4 devices/driver as yet, but if this is anything to go bye, they should be rattling the upper areas of this Database.

Hats off to the team at MOTU , its great to see that there is some focus on improving and delivering true driver performance.

The other interface I decided to have a revisit was the Presonus ( now Fender) Quantum HD2 USB interface, which on my initial testing threw a few curve balls re decisions made to attempt to get RTL’s as low as possible, that would live up to the reputation that they had achieved with the original Quantum TB units.

The above was never going to happen using a Thesycon derived driver, but instead of accepting the workable range the driver/controller offered , ventured into areas that may have looked good on a marketing spread sheet, but proved detrimental to overall driver performance.

The hope was that with the rebranding to Fender and the release of the new Quantum LT’s, that the driver had been amended and repaired.

No such luck :-(

Presonus (Fender) Quantum HD2 - 2026 Revisit !

Disappointingly nothing has changed from the original testing run , results are identical for the original V4 and new V5 UC/Driver.

On the original full release driver the decision was made to force the RTL down by pushing the Output Latency below what is practical - 128 being at nominal, 256/512 both being way below nominal, with the subsequent performance collapsing under anything resembling a moderate load.

I had initially forwarded my test findings to Presonus prior to releasing my first report, in the hope that they would acknowledge the issue presented, and resolve the respective latency settings to bring the driver back to within an operational range of the Thesycon driver being used.

My concerns were dismissed, they essentially responded that no one else had complained, that there is nothing to address, the driver is working as designed !

Which brings me to another point, not one so called “reviewer” on the web made a note of the obvious discrepancy between a normal operational range and delivered output latency, and I struggle to believe that they even tested these interfaces under any stress.

I Digress.

Summary and Conclusion !

In short, not all updated drivers perform better, and its not uncommon that driver updates actually degrade performance of interfaces at times. Of course the reasoning for updating drivers and firmware will vary, sometimes required for changes in O.S/Hardware for compatibility, sometimes for technical changes and/or features added to the interfaces, etc.

In an ideal World driver updates and/or new generational hardware/driver changes would/should always maintain and/or improve the overall performance of the interfaces, but the reality at times is not as we would expect.

Some manufacturers and developers get it, some don’t, it is really as simple as that !

New Podcast Uploaded :

Now across all of the major podcasting platforms.

DAWbench Radio Show : Episode 41

TechBytes 11 : 2025 Music Technology Round Up : The Year in Review !

A few links below, but easily found on most others with a search.

· Podcast Home Page : Here

· Apple Podcasts : Here

· Spotify : Here

Hosted by Vin Curigliano of AAVIM Technology , I am joined by guest co-hosts Pete Brown of Microsoft and Chris Mann of Link Audio.

We catch up again on what Pete and Chris have been up to since last show, get an overview of the guys adventures at NAMM, and check in on Petes work on MIDI 2.0 and the inbox Windows ASIO Driver, etc

We do a general catch up and summary of the last 6 Months in DAWbench testing and development work. We discuss the details of the official DAWbench Suite 2026 release after 3 years of development, and cover some of the most recent testing and resulting fallout and ongoing discussion.

We again cover some of the major new DAW/Sofware releases, and some cool Emerging Tech, cover some of the more recent aquisitions, and also cover the fallout from the NI preliminary insolvency actions currently playing out.

We discuss the emerging CPU and Platform Wars covering Apple M4/5 Series vs x86 vs Arm , cover the Intel Ultra 200 Series CPU’s and AMD’s X3D CPU’s refresh’s, discuss the Qualcomm Snapdragon X2 CPU release, and cover the incoming Nvidia N1X Mobile/Desktop chip.

We share some more stories from the Tech Support Trenches, and much more.

Host & Guest Links :

AAVIM Technology : www.aavimt.com.au

DAWbench : www.dawbench.com

Microsoft : www.microsoft.com

Pete Brown : https://devblogs.microsoft.com/windows-music-dev/

Link Audio : www.linkaudio.com.au

VO :

Andrew Peters : www.andrewpetersvo.com

Music Themes :

Original DAWbench VI Theme Music composed by Rob John : Independent Music Productions :

http://www.indmusicprods.com

DAWbench Radio Show ReMix by Erin McKimm : www.erinmckimm.com

All Rights Reserved : © AAVIMT 2026

As many reading in would be already aware, Native Instruments GmbH ( which is also the parent company to iZotope, Plugin Alliance, and Brainworx) has entered preliminary insolvency proceedings.

This is significant news for many of us who have invested in the products over the years, and has sent a ripple across the Music Technology community.

There are a flood of articles and videos attempting to explain and unravel what is actually happening, and the potential outcomes and consequences of the proceedings. I spent the last week digesting and doing my best to connect the dots as best I could, so thought I’d give a summary of how NI landed themselves in this situation, and what the potential outcomes are moving forward.

Lets layout the time line leading up to where we are currently.

2017 – The first big outside investment !

Native Instruments received a large cash injection from a a Munich based private equity firm called EMH Partners, who invested roughly €50 million into the company.

The goal was to accelerate growth, expansion, and to strengthen their position in the greater digital music community.

NI’s Founders and EMH kept significant ownership, so Native Instruments remained under original leadership but now with PE backing.

Think of it as Native Instruments getting a cash injection to grow faster, but now with investors who would be expecting a large ROI in a few years.

2021 – Francisco Partners Enters the Building !

Francisco Partners, a US-based private equity firm, bought a majority stake from both EMH and the founders/shareholders. EMH retained a smaller piece.

Native Instruments was now fully in the hands of bigger investors, with a strategy to consolidate and expand with other music software companies.

Francisco Partners went on a buying spree, acquiring iZotope, Brainworx and Plugin Alliance, placing the cost of acquisition on NI.

So in short, Native Instruments went from the initial growth investment to a full P.E takeover. The new owners were thinking even bigger - expanding and merging the technologies and resources with the other acquired brands, making it a more powerful option for music and audio producers.

2022-2023 – Rebrand to Soundwide, then back to Native Instruments !

To reflect the bigger ecosystem with iZotope, Brainworx and Plugin Alliance, the owners briefly renamed the holding company to Soundwide.

By mid 2023, they reverted it back to Native Instruments because the original brand had stronger recognition within the community.

To be honest, I had absolutely no idea they had even changed the parent company to Soundwide, and the first I and many others even knew about it, was when they made a public announcement about the name being “changed back “ to Native Instruments ?

From a personal perspective, during this period I noticed an elevated and annoying increase of newsletter and product promotional emails that had reached the point of spam. I remember one email stating that they had noticed I hadn’t opened and read the previous email ?

I was like WTF, how would you even know whether I had read the email or not ?

Turns out they had deployed hidden pixel tracking technology (aka web beacons) in their emails, that are used to track engagement like whether the email was opened, viewing time, etc.

If the plan was for more engagement, it backfired, I removed myself from all mailing lists associated, including ones from Izotope/P.A that I hadn’t even registered for, but the geniuses had added my email to.

I Digress

2025–2026 – Failed Sale to Bridgepoint and Bain / Insolvency Proceedings !

O.K, so now we are up to the current circus being navigated.

In December 2025, there was an attempted sale to US P.E Firm - Bridgepoint and Bain Capital Credit, but the deal collapsed , which resulted in Francisco Partners initiating the filing.

Shortly after on January 27 2026, the German parent companies (Native Instruments GmbH, Holding GmbH, Group GmbH, and Music Creation Midco II GmbH) entered preliminary insolvency proceedings.

Most likely reasoning would be due to a combination of high debt from expansion, leveraged buyouts, and the cost of acquiring other music software companies. The Group is now in the hands of a Prof. Dr. Torsten Martini, who is listed as a preliminary insolvency administrator that has been appointed to oversee restructuring, and any potential sale of assets.

Without too much speculation, that means NI’s various assets will be sold off in some form. Now a process that’s out of the hands of NI executives and owners.

I have seen various numbers being quoted for the financial standings.

Although not current, they still give a glimpse – from a 2024 filing NI reported cumulative losses of €288 million ($339US million) accrued in 2023 and 2024, with maturities looming/due on approximately €262 million ($309US million) in debt.

In a nutshell, the normal operation of the business just couldn’t keep up with servicing the vast debts , and didn’t stand a chance without a restructuring.

So in short, after the failed sale to Bridgepoint and Bain Capital Credit, Francisoc Partners and strategically filed for a German version of a controlled restructuring.

There has been some confusion regards what that means for Plugin Alliance, iZotope and Brainworx, and to be honest, as best as I could wrangle through the articles and information collected , I am still not 100% clear.

P.A have made public statements that they aren’t directly listed in the insolvency filings, so operations continue as normal.

Why the confusion?

Well, the filings are for the specific German legal entities listed prior, whereas P.A, Izotope and Brainworx are listed as US entities, but from my understanding they are still bound under the greater corporate parent company that has just been acquired ?

So one explanation is that although the parent company is in restructuring, the subsidiaries may continue doing business as normal, though they could be sold or spun off later.

Summary

Native Instruments has been on a private equity roller coaster, first with EMH investing in 2017 to help it grow, then Francisco Partners taking majority control in 2021. The brief rebranding of the empire to Soundwide and back, and now in 2026, the German parent companies landing in preliminary insolvency. Not because the companies/software are failing, but because the financial structure and accumulated debt has become untenable.

Subsidiaries like iZotope, Plugin Alliance, and Brainworx keep operating for now, though their future could change as part of the restructuring.

Have we been here before ?

To many of us in the industry, Native Instruments, and/or more specifically Kontakt, is too big to fail. But for those of us old enough to remember Nemesys GigaSampler/Studio from the late 90’s to mid 2000’s, which built a huge end user base , and had a large number of developers locked into that environment and eco space , that literally disappeared overnight after its sale to Tascam, who pulled the rug out of the whole project minutes after releasing V3, leaving end users and developers stranded.

This was the beginning of the rise of Kontakt, when it became the pseudo go to for developers, many porting their Giga Libraries to Kontakt. Over the years Kontakt has maintained the largest number of 3^rd party developers, many of which would be currently having some sleepless nights I would imagine.

Yes there are other competing sample playback engines , some appearing as dedicated engines for respective companies like East West ( Opus) and VSL, both of which were originally on Kontakt in earlier incarnations. More recently, other library developers have already been moving off the Kontakt eco space , more and more, mostly with dedicated sample engines, which I suspect are not developed in house, but are instead using engines like Gorilla Engine, and other 3^rd party alternatives.

These 3^rd party engines and associated environments are not currently in a position where they could quickly and/or easily step into and fill the void of Kontakt, so options are not as clear as back when Giga failed.

So whats my read of all of the above ?

I personally believe Native Instruments will survive in some capacity moving forward, the Kontakt Environment alone is just a huge eco space that has significant commercial value, as way too many developers are dependent on it. So, I am not expecting another Giga moment. As to the other hardware/software products, that might be a harder call.

All we can do now is wait to see where the dust settles once the proceedings are completed in Germany.

*Update March 08 2026 : Native Instruments to be acquired by inMusic.

Official announcement from Native Instruments CEO Nick Williams. Here

With all things considered, this is probably a best case outcome scenario for the end users/community, as NI remains intact with all brands surviving ( for now ).

No idea re the actual finer details of how this got across the line, and we may never know, well those of us mere mortals not privy and/or under NDA.

As long as they haven’t jumped out of the fry pan so to speak.

For the interim at least those dependent on the Kontakt Ecosystem can take a breath, but part of me still gets a sense that this should be a wake up call , and an opportunity to explore alternatives.

DAWbench 2026 Benchmark Suite : Development : Tales from the Trenches !

After 3 years in development, today I officially release the DAWbench 2026 Benchmark Suite. My initial brief was to update all the sessions to be 100% cross platform compatible, use only Freeware plugins/instruments/libraries, move the plugins/instruments to the latest plugin protocols of VST3/AU, and to make the VI Kontakt session more accessible and easier to run.

The previous versions of DAWbench VI required a full version of Kontakt, and were using legacy library files from Kontak 3 that proved difficult to port to the later library format used. Although we could get the sessions running on the later library format, ideally the original legacy library files were required which were not available in current Kontakt versions. I was unable to offer the legacy library files publically, so testing was reserved to a small circle of trusted testers that could successfully access the legacy files.

1st box to tick was to move the original DAWbench VI session to Kontakt Player, and find compatible Freeware Libraries that could carry the VI test session. Over the course of the development, I investigated and tested a large number of library options during the extended BETA period, and quickly realised this was going to be harder than I thought, as many Freeware libraries, required the Full version of Kontakt, and were incompatible with the Freeware Kontakt Player. Say What ?

Add to that, a number of the Freeware Kontakt Orchestral Libraries were proving to be either very limited and/or inconsistent, so it took a lot longer than I had anticipated to find a solution that I was happy with.

The original Orchestral library sounds were from the core VSL sourced Full Kontakt Library, which weren’t anything overly spectacular, but worked very well in context, so I didn’t imagine they would be that difficult to replace. Famous last words.

2nd box to tick was to retire the legacy VST2 DSP plugins that had been used and were the staple over the years, and find stable Freeware plugins that would use similar levels of resources, which could be used across the expanding range of DSP test sessions. That proved easier than the sample libraries, but I went through quite a few different plugins before settling on the selection that made the final call.

3^rd box to tick was that I wanted to reintroduce other DAW’s back to the Suite, that had been gradually being scaled back to just Reaper over the last few revisions for reasons that I will not bore you with now. DSP sessions are now across 5 DAW’s - Bitwig, Cubase, Reaper, Sonar, Studio One.

4^th and last box to tick was to develop a VI test session based on Modeled Synths, which has been long overdue. Again using Freeware instruments to make the session more accessible.

O.K, with that out of the way, let’s get into the details.

DAWbench DSP 2026

DAWbench DSP/BUS have been updated using Analog Obsession VST3/AU Plugins, 640/960 extended plugin versions of the DSP session using the TUBA plugin running 4x oversampling, which has an individual resource footprint similar to the OG 1566 plugin. Difference here is that the 4x oversampling does introduce some inherent delay per plugin, so the DAW’s PDC is working through that as each plugin is enabled in real time.

The DSP/BUS session utilises TUBA on the standard incremental tracks as per the DSP session, but has additional FrankCS plugins in the BUSS’s that can be used to add additional processing either serially or in a combined parallel manner.

DAWbench DSP MIX is the new session based off a Real World mixing project which has Tracks/Groups/FX Buss’s/Sub Buss’s. The DSP MIX session rounds out the available test sessions, and adds the last element which moves it from being a purely empirical saturation test, to one based on a Real World Test session that can be used as not only a stand alone reference stress test of a large RW Mix session, but also includes an additional element of being able to incrementally and empirically increase the load to further saturate the systems that were capable.

A wider variety of plugins are used over and above the Analog Obsession used in the DSP/BUS sessions, and also includes plugins from Acon Digital, Chowdhury DSP and TDR

DAWbench VI SMP

DAWbench VI SMP ( Sampler ) is a heavily reworked and updated version of the OG DAWbench VI. Main instrument is now Kontakt 8 Player, and the libraries used are Kontakt Factory Selection 2, which is from the NI Komplete Start Freeware package, and Sonuscore’s - The Orchestra Elements Freeware library.

Session also uses Steve Slate Drums SSD5 Free Drum Sampler, and the Wave Alchemy Magic 7 Reverb. TDR NOVA Dynamic EQ is featured across all the instruments tracks as well.

Musical elements and arrangement have been edited, tightened up and remixed, fresh samples and patches tweaked and assigned for all instruments, drum groove is now MIDI playing through the SSD5, instead of a sampled drum loop.

DAWbench VI SYN

DAWbench VI SYN (Synth) is the newest and latest session that rounds out the suite for 2026. This has been long overdue, and I have been testing a stack of Freeware synths over the years to thin out the herd, so to speak, for viable candidates. My initial idea was to do a One Synth Challenge which I had completed using the Surge Synth Team’s Surge XT synthesizer. Full arrangement and all parts ( except main drums) were driven by Surge XT’s extensive palate of available sounds, but as I progressed further I decided to widen the umbrella a bit further and introduced OB-Xf, which is another project by the Surge Synth Team, and also Vital Audio’s Vital Wavetable synth, which is very popular and widely used.

Musical elements finished off with Drums driven by 99 Sounds Drumplayer, TDR NOVA Dynamic EQ is again featured across all the instruments tracks, with Wave Alchemy’s Magic 7 Reverb again handling master reverb duties.

Composition was written, programmed, produced, mixed by yours truly. I do prefer to spread the love re participation in creating the musical elements in these sessions, but I was getting weary of promises from several friends to write me an EDM banger, that never seemed to materialize after 2-3 years of asking. So, I channeled my PsyTrance Mojo and knocked out the track. I doubt it will set the World on Fire, and it is a very busy/crowded 8 Bars only, as I piled on the number of instruments in the arrangement to pad out the processing load. Does the job, watch out for the subs.

I’ll finish off by saying that I have no affiliation or vested interest with any of the company’s who’s products I have used to create the 2026 Suite. I have chosen the products purely on merit for being able to complete the required tasks reliably in the sessions, and I also actually really like and use the plugins, instruments and libraries myself, so if that encourages others to check them out, win/win, as there are some really nice tools available in the Freeware/Open Source Space.

That’s it for now, on to the next !

Sessions available for download @ DAWbench.com

Continuing on from where we left off in Part 2, it was nearly 18 months after we had closed off on the initial phase of the testing with DAWbench MIX, that I was tagged and dragged into the increasing discussion surrounding the issues we had previously highlighted regards multicore thread management routines and premature overloading of ASIO-Guard.

During that time tho, I had stayed on top of the shifting dots regards Cubase’s threading routines, and noted when doing the initial R&D for the Intel Z890/Ultra Series (15^th Gen) CPU’s around Dec 24/Jan 25 running Cubase 14, that the thread management routines seemed “confused” regards what was a P and E Core after Intel had changed the actual order of the P/E cores in the layout of the die, and subsequently how Windows Scheduling/Intel Thread Director identified and presented the order in Task Manager. Steinberg’s threading routines seemed to be still arbitrated the threads in the order of the 13/14^th Gen P/E Core layout, which was evidence enough for me that they were still enforcing bespoke core affinity routines overriding the Windows Scheduler and Intel’s Thread Director routines.

At the time I just threw my arms up, made a note, archived all the data and screens in case anything changed and moved on, as I wasn’t overly interested in engaging with the gallery and/or bringing it to Steinberg’s attention, only to be dismissed and/or ignored.

By November of 2025 things were starting to escalate online regards end user reported issues with Cubase’s Core handling and/or ASIO Guard prematurely overloading, and as noted previously, I was tagged and dragged into the discussion, breaking my self-imposed exile at the Steinberg forum where I hadn’t participated for over 15 years.

I don’t usually quote or reference information posted at forums as a rule, unless its directly related to and by people involved with the DAWbench project, but I will be quoting directly and posting references to some comments made by Steinberg reps that are relevant to the commentary that I will present in this article.

DAWbench DSP MIX-EXT : Cubase 14 : Intel 285K

To highlight the shifting dots regards thread management routines with the Intel 285K that I had noted earlier, this is the DAWbench MIX-EXT session being run on near identical spec’ed systems 11 months apart. The 1st screen is from early Jan 2025 , Cubase version would have been 14.0.10, 2^nd screen is mid November 2025, Cubase version was 14.0.40 at the time. It’s evident that there has been some work done regards core affinity/thread management routines during the C14 version cycle.

DAWbench DSP MIX-EXT : Reaper 7 : Intel 285K

For reference, this is Reaper 7 running on the Jan 2025 spec’ed system showing that even at the very early release stage of the Z890/Ultra platform, it correctly identified the P Cores/E Cores due to its thread management routines being handed to the Windows Task Scheduler via the Intel Thread Director. Yes, the most heavily loaded Cores are the P-Cores in the order layout on both the chip and in Task Manager - 2P Cores, 8E Cores, 4P Cores, 8 E Cores, 2P Cores.

DAWbench DSP MIX : Phase 02 Re-investigation : November 2025

As I had noted in Part 2, we had closed off on the initial testing phase around Mid 2024, Steinberg had the MIX test session in their possession, verdict had been expressed, and my internal testing had confirmed that dots had been shifting, but nothing that would shift the needle as much as hoped and/or required. In short, same ole same ole , so if it wasn’t for the gallery firing up with numerous posts reporting issues that mimicked my earlier work, I was more than happy to just continue to file this under the too hard and cbf folder.

The discussion at the Steinberg forum referenced my report and managed to get some direct engagement for Steinberg reps, so I continued lurking and then when I felt appropriate joined the discussion, which allowed me to communicate directly with a rep from Steinberg, who had drawn the short straw to attempt to manage the mess, so to speak.

The discussion at the Steinberg Forum from my understanding had been splintered across 2 similar threads, so they were merged, with the merged thread (Core Handling in coming updates for W11) starting on August 21, the O.P being Magnus_N.

My work was first referenced on October 14 Here

There had been some to and fro discussion with several members leading up, which those interested can check out if interested, but Steinberg didn’t officially enter the discussion till November 7 , the reps name is Matthias Quellman, who is part of the admin team for the forum, not sure of his position in the greater Steinberg operation tho.

The initial response was to dismiss the requirement of rewriting the audio engine, which had come up a few times prior, and to request Real World session details, as opposed to theoretical max load tests, which is fair enough. Here’s the thing tho, if he was referring to the DAWbench DSP MIX test, it’s actually based on a RW session environment, and not the so called theoretical max load tests, which incidentally were actually showing balanced, linear thread management and scaling.

Requests were made to send a session so that it could be tested/traced by the audio engine team to see what was happening in those RW scenarios. Unknown to Matthias is that I actually made the same request offline for the same test session so that I could create a DAWbench version of the session logistic, as I had with the previous DAWbench DSP MIX session based off Marcus’ session. The idea was that I could add to the test session layouts that potentially triggered the ASIOGuard overrun, check the similarities and/or differences with the initial DAWbench DSP MIX sessions, to potentially narrow down what could possibly be triggering the situation.

Enter DAWbench DSP MIX MN

Magnus_N Real World v DAWbench DSP MIX MN

The first step for me was to reconfigure Magnus’ RW session into a working DAWbench session that was as close as possible to the RW session in total resources used, thread management and ASIO-Guard loading/dynamics.

Session Details:

13 x Tracks with a combination of Stereo and Mono Music Content and Sine Waves, 4 x Group Channels, 6 x FX Channels, Various DSP Plugins ranging from Compression, EQ, Saturation, Reverb, Delay, etc. Plugins used include Analog Obsession, TDR , Chowdhury DSP, WaveAlchemy.

This session is smaller and far simpler in layout and logistics than the standard DAWbench DSP MIX session, which has more tracks and complex routing with nested groups/busses. To see the same issues with thread management and ASIO-Guard, was indicating that the routing doesn’t necessarily need to be overly complicated, as even more streamlined session layouts can trip over.

Top screen is Magnus’ RW session, the screen below is the DAWbench DSP MIX MN session, and as is clearly evidenced, its near identical in session logistics and dynamics. The difference being that I can now send that session to anyone in the trusted testing pool, and run the session across a wide selection of systems to observe how the systems are arbitrating all of the above.

DAWbench DSP MIX MN : C14/C15 12600K

The session development was done on my 12600K dev system, and I pushed the processing to the absolute nth degree just below break, as I wanted something that would have at least a moderate mid to high load on later and higher end systems.

Top screen is C14, which was used for the development, bottom screen is C15 with the session opening but failing to playback, so there was a small performance hit.

Its already very evident that the thread management and core assignment/balancing for the 12^th Gen CPU’s is different to that of the Ultra 15^th Gen , which is not overly a concern as they are different architectures and core layouts, but the reserving of the first 2 cores on the 12600 is an obvious stand out. This is specific to the Intel 12-14^th Gen from my understanding, as it is not evident on AMD Ryzens systems either.

As we progress further with the testing this year across other systems and platforms, I’ll do my best to include this session into the testing pool to see how it behaves across other environments.

DAWbench DSP MIX-EXT : Intel 265K/285K

While I had Magnus’ time and energy available, I asked him to also run my DAWbench DSP MIX-EXT on his 265K, as I had no reference for the test on that particular CPU, and it would be interesting to see how the thread management/core assignment would be arbitrated across 2 CPU’s within the same architecture family, but with different core counts.

What stands out for me is that the final 2 P cores on the 265K are not being utilized, so IMO, its again pointing to a more rigid core affinity routine, than a scheduled assignment where the P and E cores are being recognized and arbitrated to correctly.

Down the Rabbit Warren We Go… !

At this point we had pretty much closed off on the testing at our respective ends, Steinberg had yet to forward any further information re results from traces, etc, and for the most part we had collectively settled back into a holding pattern waiting for any official additional information. We had accepted that this issue was specific to Windows, and that Cubase on MacOS was using a more streamlined and conventional thread management procedure using Apples appropriate API.

Quote : Matthias_Quellmann, post:111, topic:1006105

“On macOS, our audio engine communicates with the operating system through the *Workgroup API*. With this setup, macOS handles the thread scheduling based on the information it receives. So again, we didn’t rewrite the audio engine for macOS, we just use the available API to improve the communication.”

Of course this was in response to, and in context of why the same cannot be applied on Windows using the appropriate scheduling routines. The discussion headed into areas of technical debt and the associated curves that would be required to be navigated, the whys and why nots regards timelines and expectations vs realistic outcomes, etc, etc.

I did engage directly with Matthias further on, with the conversation remaining mutually respectful and polite, which was much appreciated by all involved in the thread. Some good exchanges and way too many details to cover in this article, but I do suggest navigating across and having a read through the exchanges that followed after that post.

So for those of us on Windows, it was pretty much settled that the issue resided within the complexity of the code base on that platform, and that Cubase on MacOS was not affected, or so we thought within the information available to us.

Then this happened !

DAWbench DSP MIX-EXT : Mac Studio : M3 Ultra 28 Core

This system was purchased by Marcus, as he had reached the end of his tether regards circumnavigating the thread management and ASIO-Guard overrun issues on Windows with his Ryzen 9950X ( he had upgraded from the 7950X used in the preliminary testing listed in the last article), and was wanting to get away from the mess and jumped platform to get what he believed would be the appropriate thread management and ASIO-Guard performance for the core counts on offer.

To say it was a shock to find that the same threading and ASIO-Guard premature overrun dynamic was also evident on MacOS once the core count tipped over a specific number of cores ( the ceiling number which we are yet to confirm as of this writing ), is an understatement.

When the information was presented to the community at the Steinberg forum, the response was nothing short of ridiculous IMO, immediate denial and dismissal that there was actually anything wrong with the performance and threading dynamic being displayed. A circling of the wagons by the Mac faithful ensued, playing gatekeepers by high jacking and misdirecting the conversation to the point it was abandoned. Absolute waste of time and energy attempting to engage further, but one of the faithful in their ramblings dropped a few bread crumbs, stating that there is nothing to see here, that its simply Steinberg using their bespoke core affinity routines, and that there was nothing to fix ? (Paraphrased, not worth linking to.)

WTF ?!

So, I started following a few breadcrumbs that Steinberg were possibly using said bespoke core affinity routines, which I had suspected, and had been commenting on for years. Following one crumb after the other, I stumbled on a few pearlers that had slipped under my radar due to non-participation at the Steinberg forum for so long.

Quote : Ed_Doll, post:69, topic:876876

“The processor affinity seems to play a role in here. To carry out the optimizations for the newer hybrid CPU environments, we had to change the behaviour and older non-hybrid CPU systems might have been affected negatively by these changes. At least, this is our first assumption that we are having a closer look at now. However, this may not be applicable to all the different reports in this topic but we have to take one step after the other now. Thank you for your patience in advance.”

No Shit Sherlock !

The above quote is from November 09 2023, after the release of Cubase 13, and in response to some members with earlier gen systems experiencing drops in performance and stability. To me this pretty much confirms the hurdles we were jumping through with the 10980XE’s collapsing under certain session logistics, and the inane thread management routines mistakenly being applied to the Ryzens.

The best was yet to come tho.

Cubase 13 Processor Optimization Menu : MIA ?!

A few posts down from the one quoted above, the question was asked whether there were any options available to select hybrid and non hybrid core affinity routines, where a video was linked in a response to a Club Cubase C13 Walkthrough from November 03 2023, showing the exact options that were being requested ?

Say what ?

5.07 is actually the timestamp Steinberg posted in the video description, but 5.04 is better.

Direct Link :

Quote : Greg Ondo : November 03 2023

“ One of the other aspects that has changed is with our Hybrid CPU’s, so the Hybrid i9 CPU’s , if you have an 8+ Core system , you can have different functions for how the processors will be scaled across the systems. So it will take advantage of all the Multiprocessors, there are some algorithms for that “

So its obvious that during the C13 development cycle, Steinberg were playing with optional core affinity routines. For it to be accidentally leaked in the Official C13 Release Walk Through is pretty wild, and means that these options must have been still available very late into the final BETA cycle, and removed at the last minute.

Can’t put the genie back in the bottle now!

Questions remain, what were these optimization’s, and why were they removed ?

Is there a possibility that they will return ?

Available Optimization options listed in the missing menu.

C12 Behavior

Low Latency

Balanced

All Cores

C12 Behavior would most likely be Intel Hybrid On/Off, as to the others, who knows what those algorithms actually entailed, as they never made the release version. That Greg Ondo not only slipped up in announcing features that never made the release was bad enough, but to never respond to the questions after the video spot was pointed out in the forum thread, was even worse. I’ll place this under - lets ignore it and hope it goes away. I am amazed the video is still up to be honest, and yes I have downloaded and backed up a copy, just in case!

Also, as a cherry on top, the reference to 8+ Core CPU’s (16 Threads with HT/AMT) is smacking of the whole MMCSS mess being revisited !

Summary and Conclusion !

As I noted in the title of the article, Cubase’s Core Handling/Thread Management routines, coupled with the ASIO-Guard overruns are an ongoing enigma, which will not be resolved in the Cubase 15 development cycle, nor do I have any confidence that it can even be fully resolved seeing that it seems to be pollinating cross platform.

FWIW - We will be exploring more on the MacOS front in 2026.

My focus on this 2^nd phase of testing was simply to give assistance to some of the end users who seem to be yelling into a void, and to also get a wider pool of effected session configurations that could assist me with client support if/when they hit the inevitable wall, and to assist in work arounds.

As much as it doesn’t seem that I am coming from a position of good faith and/or intention at times, as I noted to Matthias on the forum thread, I am doing this with a deep love of the application that I have been using for 35+ years , and a genuine wish to improve the experience for all end users. It’s because I am covering areas that are not overly positive, that the intention can be skewed when viewed from that perspective lens.

In closing, I would like to thank Magnus_N and Marcus Cliffe (again) for their time and energy helping in this 2^nd Phase. I can’ t say that we got any further regards concrete answers than in 2024, but we learned a few more things, expanded the DAWbench testing pool, and discovered that we Windows users are not on an island once core counts get high enough on MacOS.

I’ll take all of the above as a positive, eyes forward , onto the next.

Picking up and following on from Part 1 where I not only highlighted the curves being navigated re X-Scaling on larger core systems environments, but also did my best to give an overview of the respective DAWbench Suite test sessions. I noted how the standard DAWbench core saturation sessions are an empirical test regiment that can be used to test potential scaling of CPU architectures in DAW environments, but Real World application is dependent on session logistics.

This is something I think is important for those wanting to understand the finer details of the reporting, and was something I admit I hadn’t made a strong enough of point of, as I made the assumption that those reading in would be aware of and acquainted with my previous work.

To assist with the above, and to get a better overview and visual feedback of how the respective session loads are arbitrated and thread managed across multiple DAW’s, its worth having a read through the DAWbench on WoA ( Windows on Arm ) ! article where I go into detail and show the screens of the respective DAW’s under empirical Parallel and Serial Saturation loadings, as well as the DAWbench MIX test session which was the focus of the previous article. The displayed dynamics are of course relevant to the Snapdragon X Processor, but the respective DAW thread management routines are still interesting regards how they are arbitrated, and in many ways are similar if not exactly the same as their respective thread management on x86.

Why I suggest reading the 2 previous articles is so that the readers are more acquainted and familiar with the information that will follow in this article, as I am going to get deeper into the weeds, so to speak. I am making this request to hopefully head off and negate sentiments that where expressed about the first article, which caused a few ripples where assertions were made that the information could be misinterpreted or misrepresented in some way regards the comparative performance of the various DAW’s.

Of course the fingers were being pointed by those that hadn’t read, and/or even attempted to digest and comprehend the main subject of the article, which was all the DAW’s were not scaling from 32 to 64 threads as expected. It wasn’t really focused on comparative DAW performance directly.

But as is typical, anytime comparative performance across DAW’s is displayed, the focus zeroes in on that aspect, and the gallery fires into action.

So what I am going to be doing in this article is taking a deeper dive into thread management routines across the DAW’s on Windows for the most part, (our Fructose friends will get a mention as well ), focusing on Cubase vs Reaper as that seems to be of the most interest and a catalyst to many, and I will also be giving full details of the initial development and testing around the DAWbench DSP MIX session, which moves away from empirical saturation and closer to Real World application.

I will also be referencing and quoting public facing comments made by company representatives regards this area, to help connect the dots to what I have been observing, experiencing and commenting on regards the shifting dots on the thread management routines and associated hybrid engine dynamics, and hopefully bring some clarity to all of the above.

DAWbench DSP MIX/MIX-EXT

The DAWbench DSP MIX sessions were developed as a result of an investigation I initiated following up on a series of reports by a close knowledgeable friend ( Marcus Cliffe of Norbury Brook Studios in the UK ), who was experiencing odd threading and MP performance scaling on his Real World Mix sessions. The initial reports are quite detailed and can be best followed in context on my GS thread Here , starting at post #1359. I am going to summarise and cover most of the details surrounding Cubase and Reaper in this article, and then expand even further from the initial test reports from 2024.

I had already been investigating issues being navigated by various Cubase clients with larger core systems collapsing prematurely in Real World sessions, which were not being picked up by the standard DAWbench saturation tests. Instead of attempting to develop an incremental/empirical Real World type session from scratch, I approached a new angle of testing after following and participating on a thread started by Marcus, who was posting some interesting information on the comparative performance of a Real World mix session across his M1 Max Laptop and his AMD 7950 desktop system.

Real World Sessions : Cubase 13

Original screens from Marcus’ testing on his M1 MAX Laptop and AMD Ryzen 7950X.

This of course opened up some discussion regards what was happening with the thread management across the respective platforms on an identical RW Mix session.

In the course of investigating, I requested Marcus create a template of the RW session, removing all audio ( copyright ), but leaving all track, grouping and bussing logistics intact, that I could use to develop a RW test session using easily available Freeware Plugins, and replacing musical and audio elements with the available resources in DAWbench DSP.

DAWbench DSP MIX – Early BETA : Cubase 13

Screens above are of the initial version of the DAWbench DSP Mix sessions running on Cubase 13, showing the freshly ported session developed on my humble 12600K dev system, and also running on a Ryzen 7950X , with very similar dynamics regards thread management.

This made no sense considering that the 12600K 6 P Core/12 Thread + 4 E-Core for total of 16 Logic Threads, is primarily favouring the 6/12 P Cores as it theoretically should via Thread Director/Task Scheduler, but also showing the same dynamic on a non hybrid 16 Core/32 Thread Ryzen ?!

For anyone wondering why there is no load on the first 2 Logical Cores on the 12600K screenshot, I’ll detail that further down. In short, it was a change made to Cubase at C13, only for Intel Hybrids.

Take note of the very similar ASIOGuard load level as well.

There is more to this, as there is a trigger point we discovered that wakes the E Cores and also the upper 17-32 cores of the Ryzen, problem being we hadn’t pinpointed the trigger as yet, and the deeper we tested with ports to other DAW’s, the more curves we encountered.

Original RW sessions were also ported by Marcus to both Reaper and Studio One, so I used those session templates to port and expand the DAWbench Mix sessions to those DAW’s as well.

DAWbench DSP MIX : Phase 01 : Cubase 12/13

With Cubase being the primary DAW and using the ported template provided by Marcus, we knuckled down and started working on developing the session by experimenting with plugins selections, until we were satisfied we had something that could be tested conveniently and consistently across multiple platforms. We would go through 8 revisions before we had signed off on the final BETA session across all DAW’s.

I developed 2 versions of the DAWbench DSP Mix session, a standard which loaded ASIOGuard to around 50-60%, and an EXT version that tapped ASIOGuard to a whisker under 100% on my 12600K.

The idea being to tip the trip point where it would wake the last available E-Cores in my instance, and hopefully the dormant upper cores on the AMD systems.

With the standard DAWbench sessions I developed the initial sessions also in Cubase 9.5, as that would cover end users testing in Cubase version C9-11. During this stage of development I tested C9.5, C12 and C13. My reasoning for testing all 3, was to monitor the change in thread management dynamics between the Cubase versions.

Cubase 9.5 being the last version pre the MMCSS amendments made to the realtime engine at C10. C12 was the last version I had on the dev system initially, but during the development I updated to C13 to get inline with other trusted testers. I wasn’t overly interested in C13 personally, but I wanted to review if there was any threading changes between C12 and C13, that Steinberg had proudly boasted about.

C9.5 will not be covered in this article as it has little relevance to most reading in, but for those interested they can read the finer details on the GS thread linked previously.

DAWbench DSP MIX/MIX-EXT : Cubase 12

C12 running an early BETA version of both MIX and MIX-EXT on my 12600K, displaying a dynamic that more heavily favours the P-Cores, which isn’t overly surprising, as it is after all marketed heavily as being optimized for the Intel hybrid architecture.

DAWbench DSP MIX/MIX-EXT : Cubase 13

Steinberg had been touting further optimizations on C13 for the Intel Hybrid chips, which resulted in Cubase’s threading model ignoring the first 2 logical cores , which were being reserved for something I hadn’t initially worked out, so essentially knocking those cores out of the available resource pool.

FYI - This model has been maintained for C14/C15

I later confirmed at least one of the cores was reserved for GUI elements - i.e, scrolling across the mixer/arrange page would results in a spike on one of the reserved cores. This spike previously would be evident on Core 3-4 from Cubase 10-12, even when being utilized for other processing

End result, the higher load session which ran on C12, would not run on C13.

So what I hear you say, well, these are closer to RW emulations, not my empirical load saturation tests, so what that means is that heavy sessions created in earlier versions of Cubase, had the potential to not run on the same system in C13 without dialling back processing load.

Not Ideal.

Even before I embarked on this testing adventure with Marcus, I was getting pretty tired of chasing these constant threading issues with Cubase , each version seemed to bring more and more curves to navigate, and I was getting more and more clients coming to me with session logistics issues where massive amounts of available CPU resources are being left on the table. I will detail one of those cases further on in the article in a wider context.

Yes, I understand that session logistics with Grouping, BUSSing and FX sends can and will shift the dynamic of what the DAW’s will be able to leverage regards available CPU power, evidenced in the screens, but something seemed skewed with how ASIOGuard was responding to the environments.

DAWbench DSP MIX-EXT : Final BETA : Cubase 13

Over the course of the revisions, I tweaked the EXT session so that there was lightly lower initial load, and then amended the Mix Busses to have additional FrankCS Inserts that could be incrementally loaded. This gave us a session that we could use in the same manner as the regular DAW DSP sessions to incrementally scale additional processing power on systems that were capable. This layout BTW has been maintained for the final release version of DAWbench DSP Mix coming this year in 2026.

Session Details :

35 x Tracks with a combination of Stereo and Mono Music Content and Sine Waves,
6 x Group Channels, 8 x FX Channels, 8 x BUS Channels , Varying DSP Plugin load depending on test session ( Standard/EXT), EXT version also has additional FrankCS plugins for incremental load. Plugins used include Acon Digital, Analog Obsession, TDR , Chowdhury DSP.

Screens above are of that final DAWbench DSP Mix Rev 8 BETA sessions running at just below the point of break, respectively on a 14900K that I had available on the desk, and Marcus’ 7950. We did manage to wake the E-Cores on the Intel Hybrids to a degree, and the final 16 on the 7950. It needs to be noted that it is introducing elements of a simulated saturation test, as during normal Mix loads, the E-Cores and 17-32 on the 7950, for the most part, still remained relatively unused.

Core Parking was not a factor in the above on either chip, and in respect to the 7950X, Core Parking would show a pattern dynamic of more odd/even loading of cores, not in a block of logical cores.

I expected the above dynamic between the P and E Cores on the Intel chips, as that was somewhat expected and accepted behaviour, but for it to be also applied to the AMD Ryzen chips made no sense what so ever as I have noted previously, and was the reason I was becoming more and more vocal about my suspicion that Steinberg was using bespoke threading/core affinity routines to attempt to outsmart Windows scheduling, and had somehow incorrectly applied it to the Ryzens.

Lets say that was starting to raise some eyebrows , and also the shackles of some that claimed I was just making assumptions without having any clear confirmation of what was happening technically with the audio engine, as only the audio engine dev team could possibly confirm/deny what was happening in any detail.

Sure, but I was basing my assertions on Real World practical experience and observation, so although I may not have had any hard technical evidence, I didn’t really need the under bonnet technical details, so to speak, as the end user experience and observed behaviour was more supportive than dismissive of my suspicions.

DAWbench DSP MIX/MIX-EXT : Final BETA : Reaper 6

Reaper 6 up and running on the 12600K, with both the standard and EXT versions. 2nd screen shows the EXT version with additional incremental plugin loaded across the respective Mix Busses.

Reaper is running 42 additional FrankCS plugins over and above the EXT template. Cubase would muster an additional 1-3 plugins depending on version.

I should note the engine still isn’t fully saturated; I could probably load another 3-5 plugins.

This is what we would ideally expect to see when DAW’s are efficiently thread managing across the available (Logical) Cores. The Intel Hybrid does throw some additional curves in with Thread Director, but Reaper seems to be arbitrating with both Thread Director and the Windows Task Scheduling to better utilize both P and E-Cores.

As is clearly evident on the 2^nd screen, Reaper has managed to wake and utilise the E-Cores appropriately, which were being ignored in the primary preload, and only activated once a trigger point was reached with the P-Cores.

The next and final stage of the testing was seeing how these sessions thread managed and load balanced across the AMD Ryzen and Apple Silicon CPU’s.

Screens from Marcus tell the story.

This is the first time we really see a consistency across CPU architecture types and across operating systems. We need to remember that this whole adventure started by investigating why Marcus’ 7950X was essentially ignoring the bottom 16 Logical cores, and to narrow down what the possible variables were, i.e, DAW/OS/CPU, etc.

Reaper is indicating that this is pointing towards being DAW specific.

FYI - Reaper on the 7950X activated and ran an additional 70 FrankCS plugins over and above what was possible with Cubase, which is no small amount, in any ones book.

DAWbench DSP MIX SL - Widening the Test Session Pool !

Before embarking on this latest adventure, I had been navigating a similar performance issue with a Cubase client a few months prior, and had been doing my best to help him circumnavigate the issue as best we could.

This is what initially drew me to follow up with Marcus when he reported similar issues on his original thread.

At the time I didn’t have the facility to test the working environment away from the client system, but with the procedures I had developed with the DAWbench DSP MIX session, I configured an additional DSP MIX session directly off the clients RW Mix session, which in a similar manner to the session from Marcus, had been prematurely collapsing ASIOGuard.

I again ported the session as a template with tracks/bus/FX place cards and then reassigned my licensed audio content, and freeware plugins to simulate the clients mix environment. Once ported, the session was sent back to client to compare to the RW session to ensure the threading/ASIOGuard dynamic was the same.

Client system is an X299/10980XE, which many reading in would have, and is a powerful staple for many working with large VI/sample based composing environments. Session template is around 50-60 tracks of audio with grouping/bussing assignments which are not overly out of the ordinary you would think, but in this session logistic it would collapse ASIOGuard in his RW sessions, even with hardware buffer set to the highest of 2048/AG set to High.

Obviously not ideal, and warranted further investigation.

DAWbench DSP MIX SL: Cubase 13

So what are we looking at with the screenshots ?

3 screens of the 10980XE running 18/36, 16/32, 16 Threads Total.

The idea of running the 10980XE at the 3 different levels was to see whether first being a 18/36 core CPU and being above 32 threads was having an impact. We then moved down to the peak of the DAW goldy locks zone of 32 , and then went one step further, disabled HT and knocked the total back to 16.

The screens tell the story , at 18/36 thread management was mostly landing on 1 core, with a spattering of load across the remaining. With 32 it just turned into an erratic spiking mess across a handful, but when knocked back to 16, we still get spiked cores, but it settles back to something closer to resembling an expected thread management.

None of the above is making any technical sense, and even less so when we move the exact same session across to other CPU architectures.

Note : Session wouldn’t play on the 10980XE on any of the above configurations, as when developing the session on my 12600K, the ASIOGuard load proved to be a touch over the processing capability available for the 10980XE, but we maintained that level of processing to test the more current architectures.

The last 2 screens are the session running on my Intel 12600K dev system and on Marcus’ AMD 7950X

Threading dynamic for the Intel is pretty much what is expected on the hybrid chips, first favoring P-Cores. The AMD 7950 again just showed the same dynamic incorrectly applied on a non hybrid chip - which has been a focus throughout this series of testing.

Both however thread managed and ran the session easily at 512/ASIOGuard standard.

I could actually run the sessions all the way down to 128, and have run the session on 14700K/14900K with similar results. I’ll put that down to brute force, higher IPC, clockspeed of the more current systems giving enough headroom to run the sessions.

We are still only talking 10-15% resource usage , and will get possibly around 20% max before ASIOGuard collapses.

So what can we extract from all of the above, as well as all the other testing leading in ?

There are 2 distinct, but possibly linked behaviours being experienced and navigated.

First is the thread management behaving differently per CPU architecture, which makes no technical sense unless Steinberg are using bespoke core affinity routines and have attempted specific optimization per CPU architecture / family type.

Second behavior is ASIOGuard’s premature collapse, which is evident in varying degrees, and quite elevated on the earlier Intel 10980XE.

The whole premise of ASIOGuard is to enable higher performance in the exact scenarios we are exploring - non realtime critical, high track count, heavy resource Mix sessions , but something is obviously not performing as expected within the hybrid process.

Closing Off on Phase 01 !

After untold hours of testing, revisions, retesting across a period of 5-6 months which we concluded around the middle of 2024, all involved decided to close off and focus on more important things!

At that time I had no direct communication, but I know that Steinberg had been made aware of the testing and concerns raised with both the cross platform thread management and ASIOGuard performance, and communicated that there is no solution to the concerns raised.

They confirmed that there was a prefetch buffer (ASIOGuard) accumulation and overrun, with no immediate workarounds to be offered, passed changing session/logistics layout, and/or freezing ?!

Make of that what you will, but that was a full stop for me.

I was very happy to be signing off on this adventure.

Just When I thought I was Out…. !

Borrowing a line from one the all time greats, just when I thought I was out…, they dragged me back in…!!

Around November 2025 I was dragged back into this adventure when my previous article was tagged in some online discussions as I noted, and in the process of navigating some of the chess moves, I revisited and expanded the testing and investigation again , and this time was able to directly engage publicly with some of the powers that be.

I’ll cover that in Part 3.

Cross Platform comparative DAW performance is still an ongoing enigma, to be sure, and the next chapter has even more twists and turns navigated.

This is a continuation of the first Substack article on Audio Interface - Low Latency Performance that I published in May 2024, that can be found Here:

https://dawbench.substack.com/p/audio-interface-low-latency-performance

For those that haven’t read the previous article, it would be worth a read to get the finer detail of the information being presented.

Throughout 2025 I worked extensively on my WoA R&D, which has included testing all the available interfaces that have released native ASIO drivers for the platform, which has been an ongoing process as drivers went through several iterations and updates during the testing phase. Data presented is from drivers that have been through a few cycles and are stabilized.

I am keeping this separate to the main LLP threads and articles as it will just cause confusion with the main Database, as the test sessions are completely different, as is the DAW being used, so no correlation to the ongoing x86 Database which I will continue to maintain.

DAWbench 2026 – LLP Test Session Details for WoA.

Reaper is being used as the reference DAW for WoA, DSP plugins are ReaFX RXC INT ( Native) and Analog Obession TUBA (Emulated ). VI test is now being run on KONTAKT 8 Player ( Emulated ) with a different set of samples. Due to some of the elements being run under emulation, I consider this a preliminary Database, which will be amended when all plugins are running natively.

LLP ( Low Latency Performance ) Rating : WoA ( Updated March 2026 )

There is a full explanation on the LLP Rating in the first article, but in summary.

3 reference benchmarks are used - DAWbench DSP – RXC ( INT) and TUBA, and the DAWbench VI benchmark using Kontakt 8P

The results for the DAWbench DSP across the latencies of 032 thru to 256 ( which has been the M.O for the last 14 years ) are added and the total is then % wise gauged against the result for the RME UFX+ baseline interface. The same is then calculated for the DAWbench VI CV/ NCV tests for 032-512.

Those 3 % results are then added and divided by 3 to give an average % .

I thought it important for the I/O and RTL figures to be an influencing factor on the rating as some cards have a lot lower overall latency than others, so the average % results is then multiplied by the last % result for the RTL to give the final LLP Rating.

LLP WoA : Getting into the Details ( Updated March 2026 )

An overview on each Interface in order.

RME UFX+ USB3 : This is the LLP Database reference interface despite not being able to run the VI session at 064 , the lower I/O and RTL results elevating it to the top rating.

Performance overall is very solid , the only concern for me atm is the lack of being able to playback cleanly at 064 on the VI test, but until I get KONTAKT running natively, I am not drawing a line under that just yet.

MOTU M2 : This is the latest entry ( March 2026 ) , and MOTU’s first run at a WoA native driver, and to say they have delivered is an understatement. Results close to on par or above in the respective benchmark sessions, with I/O and RTL rivaling the reference RME UFX+ USB3 reference interface. All round great performer.

Steinberg UR22C : This is actually my WoA R&D default reference interface, as it delivers better overall performance across all the buffer settings. The Yamaha driver is the only driver currently managing clean playback at 064 on the VI test.

I/O and RTL is higher than the RME MADIface USB driver used on the UFX+, but delivering great results for a USB interface.

RME UCX USB : This unit uses the original RME USB driver, and as per the UFX+ , I/O and RTL is very close , performance is near identical , but missing the 032 Buffer settings as the original driver only offers a true 048. Performance from 064-512 is near identical to UFX+

Audient EVO4 : There is little to no detail about Audient actually having WoA native drivers, and I was only aware after being directed by Pete Brown to a post from last year on their FB page.

There is zero, and I mean zero, information on their website on the interface product page, spec, driver download page, so I find that a little weird to say the least.

Even more interesting is thats its a Thesycon driver, which means that Thesycon have a native Arm64 driver available for any of their clients using their OEM solutions. The list there is long, but none have released an Arm64 driver apart from Audient, who almost seem to be keeping it a secret?!

All that aside, performance was stable and akin to their upper tier x86 drivers being used by multiple manufacturers that I have tested over the years. I/O and RTL is middle ground, but par for the course for their solutions.

Focusrite Scarlett 4i4 G4 : As has been reported and maintained over the years, Focusrite continue to have their delivered I/O and RTL one setting out from what we would normally expect, which is why I test with the delivered I/O and RTL, and amend the chart to reflect the Panel anomaly, for want of a better word.

Whats interesting in the testing being shifted to Reaper is that the Reaper engine runs on a RT Bloc being reported by the nominal value of the Control Panel , so the actual I/O and RTL are reported and arbitrated correctly re PDC, etc, but the RT bloc processing is one level down from the other interfaces.

Confusing, you bet !

I have been attempting to get Focusrite to address the mismatch of the Panel Settings and I/O and RTL delivered values for years, to no avail, but this is the first time I have actually seen how it can effect overall performance in respective DAW’s.

I originally thought it was more cosmetic and wondered why there was so much resistance to match the Panel Settings to the Delivered values, but have now realized its a lot deeper than that, and that there is some 2x buffering between the bloc buffer and delivered latency buffer.

In short, the reason the VI test has failed at 128 here, is because Reaper is working on the RT Bloc Buffer of 064!

My head hurts.

Steinberg IXO22 : This is another interesting one for me.

I have tested the Yamaha driver across multiple interfaces over the years, results would shift around a bit , sometimes reporting I/O correctly, sometimes misreporting , it was always a bit of a crap shoot to be honest.

I initially bought this interface for the WoA R&D work as it was the one being used at the Snapdragon Summit launch in 2024, and also because Yamaha is developing the Inhouse ASIO driver with MS for W11.

I/O and RTL was not as expected and/or I had hoped. There is a large unreported value in I/O and RTL compared to the UR22C using the same driver, so I can only guess its due to the controller being different. Which will explain the different results with all the other UR interfaces, that being they are not using a consistent controller, like for example RME.

This results in widely varying end results using the exact same driver.

Delivered performance across the benchmarks was actually better than the UR22C, at the expense of a higher I/O and RTL, but then the question of Reapers RT bloc buffer comes into play ?

Focusrite Clarett+ 2Pre : Same driver as the Scarlett, despite having a different installation package/mixer applet.

Slightly higher I/O and RTL over the Scarlett, most likely due to variance in AD/DA , refer to comments on Scarlett for performance, as they are identical.

Conclusion and Final Thoughts.

This is still early days, but its great to see at least 4 manufacturers offering products with native ASIO drivers.

With the Thesycon driver being available for the OEM clients, I am hoping we see more of those manufacturers that have invested in the drivers also release native WoA drivers, but as I was reminded by a close industry friend, they aren’t free, so maybe its a chicken and egg situation there for some.

Be great if Audient actually promoted they have the drivers as well, but I digress !

If you have any further questions on the information in the article, feel free to reach out via socials or email.

New Podcast Uploaded. :

Now across all of the major podcasting platforms.

DAWbench Radio Show : Episode 40

The Art of Virtual Synth Design II : Surge XT : Open Source Powerhouse !

A few links below, but easily found on most others with a search.

· Podcast Home Page : Here

· Apple Podcasts : Here

· Spotify : Here

“It’s fun working on stuff that works!”

Hosted by Vin Curigliano of AAVIM Technology, I am joined by guest co-host Pete Brown of Microsoft and special guest Paul Walker, aka BaconPaul , who is a maintainer and one of the largest contributors on the Surge Synthesizer Team, and also a contributor to several other open source audio projects, including the CLAP plugin standard.

We discuss Paul’s early history with music and technology , and how he found his way to joining and forming the Surge team, and his ongoing role there.

We cover the history of Surge XT, and its initial development by Claes Johanson which he sold as a commercial product via his original company Vember Audio ( Released in 2005). We discuss how it eventuated that the development went down the open source route , and how that makes it unique regards allowing access to the source code to all developers, over more traditional closed loop development of other major synths.

We discuss how the Surge Synth Team formed, the importance of the team dynamic and tools, (both technological and sociological) , other projects in the Surge Synth Team beyond Surge XT, and the constantly expanding catalogue.

We take a deeper dive into the features and direction of Surge XT, its unique architecture and feature set, and discuss area’s like MPE, CLAP, MT-ESP (Microtuning ), accessibility, etc.

We also discuss the current state of Music Technology and the incoming Zeitgeist being driven by AI, and much much more.

Host & Guest Links :

AAVIM Technology : www.aavimt.com.au

DAWbench : www.dawbench.com

Microsoft : www.microsoft.com

Pete Brown : https://devblogs.microsoft.com/windows-music-dev/

Surge Synth Team :

https://surge-synth-team.org/

VO :

Andrew Peters : www.andrewpetersvo.com

Music Themes :

Original DAWbench VI Theme Music composed by Rob John : Independent Music Productions :

http://www.indmusicprods.com

DAWbench Radio Show ReMix by Erin McKimm : www.erinmckimm.com

All Rights Reserved : © AAVIMT 2025

Following up on the recent DAWbench reports that Pete @ Scan completed featuring the AMD Threadripper Pro CPU’s, which showed the huge potential overhead available with the HEDT Workstation platforms in the standard DAWbench empirical saturation test results, I thought it would be a good idea to extend some testing across multiple DAW platforms, and in particular, using a test session not used in the standard DAWbench test results, which internally I have dubbed the deal breaker.

I have made the point on numerous occasions that the available overhead is only relevant if the DAW’s can utilize the extended logical core counts, which would be largely dependent on the respective audio engines and their thread management routines. Session logistics are also a key factor in overall DAW audio engine performance, especially when Groups/Busses are heavily utilized, where it’s been shown to expose audio engines to potential over elevated stresses.

This is a very common session layout for many end users, and is something that I focused on regards developing a DAWbench test session to better replicate a Real World production session. Enter DAW DSP MIX and MIX-EXT.

DAWbench DSP MIX/MIX-EXT

The DAWbench DSP MIX sessions were developed as a result of an investigation I initiated following up on a series of reports by a close knowledgeable friend who was experiencing odd threading and MP performance scaling on his Real World Mix sessions. The reports are quite detailed and too extensive to cover here, but I will give a summary and an overview in this article to get everyone up to speed. For those that want to dive right down the rabbit hole, you can read the reports at my DAWbench FB page, but probably best to read them in better context as I summarized them on my GS thread Here , starting at post #1359.

There has always been a vocal sector in the gallery that has continually dismissed the DAWbench test sessions as non-representative to Real World application, as if it’s some constant and a given. I have always maintained that the DAWbench sessions are an empirical test regiment that can be used to test scaling of CPU architectures in DAW environments, and that Real Wold application is dependent on session logistics, but that didn’t quieten the sector.

One complaint was that the tests didn’t represent single core / serial performance, so I included a BUS extension to the DSP test, which only revealed that respective DAW’s arbitrate the serial processing in different ways, and not necessarily landing the process on a single core.

All the above still didn’t cover the varied dynamics of Real World sessions regards tracks/bussing/FX sends etc, but instead of attempting an incremental/empirical Real World type session, I approached a new angle of testing after following and participating on the above noted thread, where it was showing comparative performance of a Real World Mix session across a lower core M1 Max Laptop and a higher core AMD 7950 desktop system.

This of course opened up some discussion regards what was happening with the thread management across the respective platforms on an identical RW Mix session. In the course of investigating, I requested a template of the RW session, removing all audio ( copyright ), but leaving all track, bussing logistics intact, that I could use to develop a RW test session using easily available Freeware Plugins, and replacing musical and audio elements with the available resources in DAWbench DSP.

Initial versions of the DAWbench DSP Mix sessions in Cubase showed the freshly ported session developed on my humble 12600K dev system, to deliver very similar performance and thread management dynamics to the 7950X. This made no sense considering that the 12600K 6 P-Core/12 Thread + 4 E-Core for total of 16 Threads, was primarily favouring the 6/12 P Cores as it theoretically should via Thread Director/Task Scheduler, but also showing the same dynamic on an All P-Core 16 Core/32 Thread Ryzen ?!

To add even further to the developing mystery, there was a trigger point we discovered that wakes the E-Cores and also the upper 17-32 cores of the Ryzen, problem being we hadn’t pinpointed the trigger as yet, and the deeper we tested with ports to other DAW’s, the more curves we encountered.

Original RW sessions were also ported to both Reaper and Studio One. These sessions became the standard DAWbench DSP MIX sessions , which have now been ported to additional DAW’s, Cakewalk Sonar, Tracktion Waveform and Bitwig Studio.

On top of the the standard session templates, I also developed an additional expanded version of the test session with even higher initial DSP overhead, and also included the facility where additional incremental load can be applied across busses to test the respective DAW audio engines threading and scaling capability to break point.

This is DAWbench DSP-EXT, which is the session that is utilised in this testing and report.

Multiprocessor X-Scaling !

To streamline the report I have only included a selection of CPU’s to highlight the delivered X-Scaling moving from the more widely used higher end Enthusiast level CPU’s from Intel and AMD, and the HEDT Threadripper. I did however expand the results to include an additional 2 DAW’s - Cubase 14 and Studio One 7, as well as the default Reaper 7. I felt this would give a better indication of how the respective DAW’s were arbitrating the session logistics involved

Regards the CPU’s, the most direct head to head comparative is the 9950X v 9750WX, as they are essentially the same Zen 5 core architecture, all P-Cores , and will show the direct results of the respective DAW X-Scaling capability going from 32 to 64 threads. (X being the scaling via the increased number of cores). I have also included the Intel 285K, as that is the direct competitor to the Ryzen 9950X.

Total Core / Thread Counts.

AMD Ryzen 9 9950X : 16 P-Cores/SMT : Total 32 Threads

AMD Threadripper Pro 9750X : 32 P-Cores/SMT : Total 64 Threads

Intel Ultra 9 285K : 8 P-Cores/16 E-Cores : Total 24 Threads

DAWbench DSP MIX-EXT

The listed Analog Obsession FrankCS plugins is the total number of additional plugins that can be incrementally activated across the configured Pre-Master Busses , over and above the baseline session processing Preload.

( Amendment 19/12/2025 ) I have had feedback from the gallery that the graph alone could easily be misinterpreted, and in some way could be confusing for those who just view the graph without reading the article. I will go into more detail of the deeper investigation that discussion triggered in later reports, but for now, to better visualize what the numbers represent in the context of the DAWbench MIX -EXT session , check out the screens and descriptions below.

System is an Intel Ultra 9 285K, which is one of the systems featured in the report.

Cubase 14 : DAWbench DSP-EXT : 128 Buffer

This is the baseline MIX-EXT template, and for those that are wanting session details of the DSP MIX sessions.

35 x Tracks with a combination of Stereo and Mono Music Content and Sine Waves,
6 x Group Channels, 8 x FX Channels, 8 x BUS Channels , Varying DSP Plugin load depending on test session ( Standard/EXT), EXT version also has additional FrankCS plugins for incremental load. Plugins used include Acon Digital, Analog Obsession, TDR , Chowdhury DSP.

As is evident the session has a measurable load across ASIOGuard, thread management and scheduling across the TM is being assigned as per Steinberg’s routines.

Cubase 14 : DAWbench DSP MIX-EXT : 128 Buffer : Maxxed

The Baseline EXT session is then further loaded with FrankCS Plugins in the Mix Busses to bring the session to the nth degree pre overrun, ASIOGuard is evidently at the brink of overloading, session managed an additional 11 FrankCS Plugins.

TM showing around 30% resources used, thread management and load balancing is as displayed.

Now these next set of screens will give more clarity and a final detail of the the large performance discrepancy displayed in the charts , well at least between Cubase and Reaper.

Reaper 7 : DAWbench DSP MIX-EXT : 128 Buffer

Its already evident that the thread management and load balancing is visibly different to Cubase , with Reapers routines handing the scheduling over to the Intel Thread Director/Windows Scheduling, where it does a better job of correctly identifying and assigning the P-Cores primarily. For those wondering, the higher loaded cores are the P-Cores, and yes, that is the order of the P-Cores on the die and how they are presented in TM

Reaper 7 : DAWbench DSP MIX-EXT : 128 Buffer : Maxxed

Its clearly evident that Reaper is able to use far more of the available resources, allowing an additional 85 FrankCS Plugins, by scheduling and load balancing more across the appropriate P-Cores, as well as also waking and using the E-Cores.

Lots to unpack, and for those that haven’t read the Scan Threadripper DAWbench report linked above, it might be an idea to have a browse across that before I dive in.

As noted, the first thing that is clearly evident in the graph is that the results for Reaper are substantially above those of both Studio One and Cubase. Now to reiterate, the MIX-EXT session is a very resource heavy RW styled mix session with lots of grouping/bussing and FX sends, and a large number of processing plugins across the tracks/groups/FX send and busses. All DAW’s were able to load and play the base session template successfully. Where we sorted the wheat from the chaff is how many additional plugins were able to be activated once the session was loaded.

So regards the DAW’s, there is a sliding scale from Reaper to Studio One and finally to Cubase, where ASIOGuard was heavily loaded and prematurely overrun by the processing flow of the session. Studio One is better, but once placed in context against Reaper, there is still a lot of room for improvement. In both these instances, total CPU resources used in TM would have been at best 20% on the 9950X/285K, lower again on the TR.

This is where it gets messier, because even using the best case scenario of Reaper, the X-Scaling from 32-64 threads between the 9950X and the 7950WX ranges from 1%-8% , Studio One/Cubase managed 0-1% , and by 512 the Intel 285K had actually managed 5% more plugins than the TR 9750WX, which is pretty wild when you think of the discrepancy in the total number of cores/threads available.

When More is Not More !

Now some may be thinking, well that’s only on that very specific session layout/logistic, I could get far better scaling depending on my own working environment and session layout.

True, Maybe !

The session layout isn’t anything that would not be similar to those used in Real World mixing environments, because it is literally based on a RW mix session. I have also developed several other sessions based on clients RW sessions that differ to this one, different track count, groupings, bussing, sends, used FX, etc, and the threading / audio engine dynamic is very close if not identical.

Large Virtual Instrument-Only templates may fare better, and that is still under investigation.

So what conclusions can we draw from the results using this specific session layout over and above the empirical saturation tests ?

Well quite simply, from the experience navigating these test sessions, none of the current DAW’s are actually able to utilize and scale efficiently to the additional cores/threads above 32, once the sessions involve commonly used session logistics like grouping/busses.

The Threadrippers for many if not most would be of no value performance wise, and with the large investment overhead involved to make the leap from say a Ryzen to the TR platform, for potentially only low single digit % improvements, I would reserve that option for those with very deep pockets, and/or very specific user case scenarios.

For some additional back ground, I have been navigating numerous Cubendo clients contacting me specifically about ASIOGuard spiking and/or being prematurely overrun with 80+% of resources still available for several years now, and I really don’t have any consensus on a solution for them past changing the session logistics if possible, or the inevitable freezing/rending tracks, which feel like a cop out to be honest. But there really is only so much that can be done while the devs are in a holding pattern at best, or in a mode of denial and dismissal at worst.

That’s not to say you can’t get work done on the current higher end CPU’s , which thankfully override some of the shortcomings with the brute force combination of clockspeed and IPC, but we are still leaving 80+% of available resources on the table

Some may ask if this is actually a Windows MP scheduling issue over a DAW thread management issue, which I suppose could be explored if all the DAW’s behaved in a similar manner, which they don’t. I am not ruling out that there are some curves that need to be navigated at the Windows end as well, but I’ll defer that for the next round.

Until then.

New Podcast Uploaded. :

Now across all of the major podcasting platforms.

DAWbench Radio Show : Episode 39

The Art of Orchestral Sampling II : Sonuscore : Compose Without Limits !

A few links below, but easily found on most others with a search.

· Podcast Home Page : Here

· Apple Podcasts : Here

· Spotify : Here

Hosted by Vin Curigliano of AAVIM Technology, I am joined by guest co-host Pete Brown of Microsoft, and special guest Tilman Sillescu, who is the co-founder of Sonuscore, who are a leading, highly respected and widely used Orchestral sample library and instrument developer.

We discuss Tilman’s history in music and technology, his early forays into scoring and composition for games, initially finding success using sample libraries which then lead to larger projects utilizing full orchestras.

We cover the motivation to venture into Orchestral sample library development , and explore some of the shortcomings with other available libraries, that the team wanted to address when developing the Sonuscore libraries and instruments.

We navigate Sonuscores milestone releases and innovations, various sample playback engines, the behind the scenes drive for creativity and design, and their partnerships with other 3rd party developers. We also cover the day to day back end mechanisms for distribution, delivery, licensing, etc.

We discuss the emerging technologies and potential impacts to the industry, weigh up the pro’s and cons of AI, get side tracked with some stories of outback aussie adventures in classic cars , and much, much more !

Host & Guest Links :

AAVIM Technology : www.aavimt.com.au

DAWbench : www.dawbench.com

Microsoft : www.microsoft.com

Pete Brown : https://devblogs.microsoft.com/windows-music-dev/

Sonuscore : https://www.sonuscore.com

Dynamedion : https://dynamedion.com

Boom Library : https://www.boomlibrary.com

VO :

Andrew Peters : www.andrewpetersvo.com

Music Themes :

Original DAWbench VI Theme Music composed by Rob John : Independent Music Productions :

http://www.indmusicprods.com

DAWbench Radio Show ReMix by Erin McKimm : www.erinmckimm.com

All Rights Reserved : © AAVIMT 2025

In my previous Cross Platform DAW Performance series of articles, I have been covering the history of the initial paradigm shift when Apple moved to Intel, and how that changed and settled the CPU Architecture Wars for a long period with all sides being on the same x86 team, so to speak. I still have a few more articles to round off that series to bring it all full circle with the current playing field, which I will get to, but for now I am going to leapfrog forward with this article.

While the battle ground reignited with the more recent move by Apple back to a RISC architecture with their Apple Silicon CPU’s, there has also been a significant shift on the other side of the front line with WoA ( Windows on Arm), which has been quietly simmering away for the last decade or so. The heat has recently been turned up with some major developments, which have finally brought everything to the boil.

The primary catalyst for the current increase in momentum is Qualcomm’s Snapdragon X CPU, a RISC processor using the same base arm architecture as Apple Silicon, and following the successful move by Apple away from x86, the question has been raised whether the elevated interest could initiate a similar paradigm shift on Windows?

Having said that, things can move a lot slower on Windows as the ship is a lot bigger and harder to turn, wider use application spreading across Laptop/Tablet, Desktop , Workstation, Server, Data Center, etc, etc, whereas Apple had a much smaller vessel to maneuver - Laptop being a major focus, as well as also being able to use the same architecture for Desktop. For Apple the paradigm shift is complete, for Windows, it is still in its infancy, as breaking the x86 umbilical to Intel/AMD is a lot tougher call.

Qualcomm Snapdragon X Family :

Snapdragon X (2024) : So lets take a closer look at Qualcomms initial laptop/desktop high performance CPU, which was brought to the attention of a wider audience with the Microsoft Copilot+ PC launch in June 2024, that IMO blindsided both Intel and AMD at the time, as the later didn’t have the required NPU TOPS to achieve the Co-Pilot PC Standard demanded by Microsoft to carry the branding. Microsoft has a long standing partnership with Qualcomm over many years and iterations of the Surface products, so it wasn’t overly surprising that they collaborated on a product that was targeted at shaking the tree of the Laptop/Tablet market.

As noted previously, the Snapdragon X is a RISC processor based on the latest Arm architecture, there are 3 levels - Snapdragon X (8 Core), Snapdragon X Plus (10 Core), Snapdragon X Elite (12 Core), Upto to 4.3GHZ, High IPC, Onboard GPU, NPU with 45 TOPS ( which was a requirement for Windows Copilot+ PC’s ), 8 Channel Memory with up to 64GB of DDR5, and claimed battery life of up to 16 hours. The last point being the game changer for Windows laptops, and something that both Intel and AMD would be more than a touch concerned about competing against.

I signed off on my initial R&D testing that this article is based on around June 2025, and started collating and writing this report with the initial plan to release no later than end of June/early July, but got side tracked with some other adventures not associated with WoA that delayed me finalizing the article. In the meantime Qualcomm released their next Gen Snapdragon X2, based on their new Oryon CPU architecture.

Snapdragon X2 (2025) : Just the Elite Series released thus far - Snapdragon X2 Elite (12 Core) Upto 4.7GHZ, Snapdragon X2 Elite (18 Core) Upto 4.7GHZ, and Snapdragon X2 Elite Extreme (18 Core) Upto 5.0GHZ. Other features include Increased IPC, Faster Onboard GPU, Larger NPU with 80 TOPS, 8 Channel Memory with up to 128GB. I haven’t had a chance to do any head to head as yet, so take all that follows with a few grains, but claimed performance improvements from Qualcomm are 39% Single Core / 50% Multicore, 2.3x for graphics performance. Memory has increased bandwidth of around 12-15% on the bottom 2 tier CPU’s, and a whopping 68-70% on the top model. Last but not least, upto a 43% improvement in efficiency and battery life.

Those numbers look very impressive, and will bring the chips closer to going head to head with the current M4’s. How they flesh out in delivered DAW performance remains to be seen.

Qualcomm however are not the only game in town when it comes to the Arms Race, so to speak, as there are much larger fish to fry in the Server and Data Center space where Arm is making huge inroads already with products from Ampere (Altra), AWS/Amazon (Graviton3), Nvidia (Grace) - which paired with Hopper GPU’s, form the Grace Hopper Super Computer Chips, and you can understand why both AMD and Intel would be sweating a touch. So much so they collectively formed an x86 Advisory Group to push back against the tide. Talk about sleeping with the enemy, the photos accompanying the joint announcement with the 2 respective CEO’s pretending to be friends, was awkward to say the least !

Some of the above Big Tin tech could filter down to Desktop/Workstation, even tho they are currently focused more in the Linux space. If the tech was streamlined and filtered down to WoA , with chips focused on outright performance up to say 32 Cores, and we could have a tidal wave incoming. Nvidia have a rumored N1X chip landing towards the end of this year with 20 Arm Cores and an on board GPU based on Blackwell sporting 6144 CUDA Cores, which is, hmm, substantially more powerful than anything Intel/AMD or Qualcomm have available on board.

All the above is great, but what does that mean for current DAW/Audio Application?

At the Qualcomm Summit in October 2024, there were a few bombshell announcements that got the Audio /Music Tech community buzzing. Full details in a great article by Pete Brown of Microsoft : Here

It’s been 12 months since the above Qualcomm Summit, so what’s been happening since then you may ask ?

DAW’s : Development is gaining momentum, there are already native ports from Steinberg ( Cubase/Nuendo 14), Presonus ( Studio One 7.2), Cockos ( Reaper 7 ), Cakewalk ( Sonar 25 ), and Bitwig ( Bitwig Studio 5.3), and a recent announcement from Ableton ( Live), that they will have their native port completed by early 2026.

Plugins : Support has been slower in moving to native, but there are a lot of plugins that will work under emulation with respectable performance.

Hardware : There are native ASIO drivers from Yamaha/Steinberg, RME and Focusrite, with more incoming, but not officially released as of the date of me writing this article.

I have been neck deep in a WoA R&D and testing cycle the last few months with a number of the listed DAW’s and Hardware, and have been putting the respective DAW’s under heavy saturation stress testing across a variety of DAWbench sessions, some being 100% native, others using VST3 plugins under emulation.

Before I go into some detail of the performance of the respective DAW’s and Hardware, I’ll give some background on the test sessions being used.

DAWbench Suite 2025 BETA :

With the ongoing development of the DAWbench Suite, I have been in an extended BETA cycle for the last 18 months, so the initial plan of releasing a suite in 2024 was put on hold as we navigated a few hurdles while testing behind the scenes across platforms. Apart from Windows x64/WoA dev and testing, there has been a lot of work being done across MacOS/Apple Silicon as well. The last time I included any AS results was with the initial M1 release, so there has been plenty of water passed under the bridge since then.

The first hurdle was to develop DSP sessions that we could run across Windows x64 and AS natively, which we ticked off with a good selection of quality 3^rd party freeware plugins. I expanded the test regiment by developing some new sessions including a series of DSP MIX tests based on a Real World mix session. These DSP MIX sessions utilize a lot of Groups/Busses/FX sends, which is a widely used and very common session logistic/layout for many.

The next hurdle navigated was with the original Kontakt 6 DAWbench VI sessions appearing to not to be performing as expected on the new Apple M4’s. It was decided that it was best to move the session to Kontakt 8 to ensure 100% compatibility and optimization for AS. I knuckled down and ported the session, all 650+ instances of Kontakt in the 12800 template to Kontakt 8 Player, and replaced the original samples which required the full version library, with samples/libraries available as freeware. This will allow the community easier access to use the test sessions in future. We have since discovered the performance issue we encountered in Kontakt 6 was also evident in the Kontakt 8 session, so both sessions have remained in the test pool. More on that later.

The last hurdle, and one still being navigated, is porting the session across to WoA. The problem being that none of the respective 3^rd party plugins/VI’s being used are Arm64 native as yet. Some will not even install correctly with their respective installation routines, but will work when manually installed in the correct directories by simply dragging and dropping the .dll’s, which I had acquired from the correct installation on my x64 Windows system.

Now to be clear, when I stipulate that they work, they are correctly recognized and utilized in the sessions, but the plugins themselves are running under emulation within the respective Native DAW applications. The % impact of the emulation is not 100% clear as yet, as I have to do some additional testing back on the x64 environment and do some comparative numbers and analysis. For the interim, just make a note despite all the DAW’s being native, all the incremental loading I will be reporting across the DAW’s is under emulation.

Audio Interfaces :

The Audio Interfaces I have qualified and utilized during the testing that have full release native arm64 drivers are listed below.

RME : Fireface UCX : USB2 / Fireface UFX+ : USB3 – UCX being used as one of my initial reference interfaces in testing. UFX+ was tested as a cross reference with their 2^nd Gen USB3 MADIface driver.

Steinberg : IXO22 : USB2 / UR22-C : USB3 – The IXO22 being the reference hardware used by Steinberg at the Qualcomm Summit, and is also being used for the inbox Windows ASIO driver development. The UR22-C is my current reference interface due to having the best performance across both DSP and VI testing.

Focusrite : Scarlett 4i4 Gen4 : USB-C/USB2 / Clarrett+ 2Pre : USB-C/USB2 – I have only done preliminary testing with these drivers on the initial release.

There have been some other preliminary announcements about arm64 driver support from a few other companies, but until I have something final and official, I will not list them.

WoA : Personal History : First Impressions !

My first personal foray into WoA was way back with the initial MS Surface on Windows RT, and let me tell you, it wasn’t a pleasant experience. I have since had glimpses over the last decade or so with friends who have been heavily involved with WoA, the last time I was physically in front of a unit prior to this current round was in late 2019, where I simply stated, let me know when it’s ready for DAW usage, LOL !

Fast forward 6 Years and a lot has changed from that initial glimpse in 2019, where it could only run 32Bit applications. WoA is now able to run 64Bit apps, the Prism Emulation engine for non-native apps is very good, which for general computing, you would be hard pressed to even notice if it was even under emulation.

My test hardware is a 15” Microsoft Surface Laptop, with a Snapdragon X Elite 12 Core CPU, 32GB DDR5. I started out by doing my usual tweaks and optimizations to the base Windows installation, some of which are not all that common, i.e, I use custom task bar / start menu applications to bring the UI back to something more akin to what I prefer over the standard W11 UI – you may notice some of the UI tweaks in screens. I also installed some small utilities that I swear by for file management, etc, which are running under emulation.

All went very smoothly, the only grey area was Power Profiles, which is something that I have tweaked on x86/x64 Windows for many years with custom profiles specifically for DAW usage. There have been more than a few discussions with my trusted colleagues over the last few years regarding some changes that have been introduced with W11 on the regular x86/x64 environments, which I won’t go into here, but needless to say there wasn’t consensus on whether the older tweaked profiles are still working as expected.

Power profiles on WoA are a completely new ball game, no option but Balanced available unless you brute force a High or Ultimate Performance profile onto the system with command line, which is not something I wanted to do unless I was sure they would actually work with the Snapdragon architecture. I adjusted what I could with the available Balanced profile, installed some DAW applications and audio drivers, and started the initial DAW testing.

Initial Testing and Curves Navigated.

On to the initial stress testing in a DAW environment, I started with Reaper, which is renowned for being one of the best at thread management/task scheduling. My main focus was to observe how the incremental load was being thread managed, and the behavior of the core clocking under the available Balanced Profile, which is typically not the optimal configuration for low latency / heavy processing environments required for DAW usage. My initial concerns were verified when I witnessed the thread management / task scheduling assigning the progressive incremental load only to the first 4 Cores in Task Manager, and the clock was not waking up and rising to the base clock as expected. The clockspeed remained under 1Ghz, even though there was substantial processing that was now being applied via the DAW. Processing rose to around 30%, i.e, the top 4 cores were now close to peaked, before the clock woke up to over 3Ghz. As the load increased further, the task scheduling then started to assign the following 4 cores, and then as they were saturated, the final 4.

The above task scheduling behavior is something that I had not witnessed before on anything I had configured for DAW usage in x86/x64 environments, and I suspected that the Balanced Power Profile was most likely causing some, if not all of the dynamic being witnessed. With this being my first look at the WoA environment I had no idea what to expect and/or if that was a typical dynamic regards task scheduling. I reached out to Pete Brown @ MS with my concerns re the Power Profile, and my hesitancy to apply custom Performance profiles from my regular x86/x64 configurations, and he suggested that it might be worth trying the “Best Performance” setting in the W11 dedicated Power Profile menu.

My first comment was, what W11 Power Profile menu ? LOL !

Windows is still attempting to serve 2 Masters in some respects, with overlapping settings being available via the new “Settings” menu, and the older “Control Panel” menu, which old dogs like myself traditionally use as the first go to. Long story short, assigning the power profile in the W11 Settings menu to Best Performance completely changed the dynamic of the thread management and the clocking. Clockspeed immediately jumped to peak available as soon as the DAW was opened, thread management and task scheduling behavior was as expected as I incrementally increased the processing load, aka, this was more akin to the typical High Performance profile I was a accustomed to, but very simplified, as it didn’t have advanced property options. Having resolved both the clocking and threading dynamic, I was now confident to move forward.

To be clear, and for those wondering, when using the usual tweaked High/Ultimate Performance power profiles on x64 Windows 11, that have been assigned as per normal in the Control Panel, it locks/greys out the W11 Settings power profile options. So there is a deeper level interconnect in play across the 2 menus. The Settings menu options are only available when the default Balanced profile is selected in Control Panel. Not confusing at all !

I should also add that certain DAW’s can activate customized power profiles from within the DAW. Cubase is selectable, thankfully, as it’s just a copy of the tweaked Performance profile we have been utilizing for ages, Pro Tools however forces a profile change without telling you, so say for example you had a tweaked Ultimate profile by default, it switches it to its own Performance profile without warning you. Genius !

O.K, I digress, where were we ?

It was now time to dive right in to the DAW apps. My initial testing was in Reaper, as that is the default reference DAW for official DAWbench testing and reports, and I had additional sessions that were using 100% internal plugins, which ensured everything was running native.

Reaper 7 !

DAWbench DSP-RXC-INT

This is the standard DAWbench DSP multiprocessing saturation test that applies a progressive and incremental load horizontally across 80 tracks of audio. Thread management is more empirical than a RW session as each incremental plugin load is assigned sequentially per track in essentially an ideal wide/parallel fashion. It can still be useful to highlight respective DAW thread management and shows the dynamic of the respective audio engines in regards to scaling per buffer settings. This test utilizes the Internal ReaXComp, each plugin having 32 bands active. Yes I know, why so many bands ? The bands are simply a way for me to incrementally scale and increase individual plugin load over the years as the CPU architectures improved. It originally was 4, then 8, 16, now 32.

This INT test being 100% Native and using only Bundled Plugins, also allows us to use the test session across Windows x64, WoA and MacOS equally, without any potential 3^rd party plugin variance.

The screenshot shows the session running at 032 samples on the UFX+, very heavily loaded (124 32 band RXC plugins), with near perfect load balancing across the 12 cores by the DAW’s thread management routines via Windows Task Scheduling. Playback was solid, driver performed perfectly at the lowest latency under heavy load. Win/Win !

DAWbench DSP-TUBA

Same session template and testing procedure as prior INT session, but this time using the Analog Obsession TUBA plugin @ 4x Oversampling as the incremental load plugin. This plugin is not Arm64 Native, so each instance is running under the Windows Prism Emulation engine, which proved to be extremely fast, efficient and stable, as I managed to push this session equally as hard as the session running native internal plugins.

It needs to be noted that each plugin instance has inherent delay due to the 4x oversampling, so the DAW is working overtime calculating plugin delay compensation, in real time, every time I activate a plugin while the session is playing. This places a high demand on the audio engine/driver stability, and it remained solid though out. This session is running on the RME UCX @ 64.

DAWbench DSP BUS-TUBA/Frank CS - SerialLoad

The DSP BUS test was developed following ongoing discussions within the community regards clock vs core session logistics, and that I should develop a test session to specifically test for serial/single core processing. Of course it was discovered that it’s not as simple as a serial process always landing and spiking on a single core as per the original premise and argument, and specific DAW’s thread manage the serial processing differently. To make things even more complicated, the threading dynamic also shifts depending on hardware buffer settings, CPU architectures, numbers of cores, etc.

The DAWbench DSP BUS session is very flexible as there are multiple test that can be run using the session layout and logistics , which can also be used for the standard parallel test if required.

For the BUS testing I developed multiple test scenarios.

1: Preload/PostLoad

PreLoad : Activate the plugins across the sine wave tracks as per the usual DSP test to apply a parallel load of 50% in the TM ( Task Manger ) across all available Logical Cores.

PostLoad : Activate the insert plugins on BUS 1 serially ( vertically ) until buffer overrun/breakup , this gives a value of serial processing available after a moderate parallel load has been applied to a session. Similar to mixing environments.

2: SerialLoad :

This is s straight serial load of the BUS without any prior parallel plugins loading. Activate the insert plugins on BUS 1 serially ( vertically ) until buffer overrun/breakup , this gives a value of the serial processing ( single thread ) capability of the CPU.

3: Preload/BUSLoad

This is a combination of the Preload test across the sine channels, and then applying incremental load across all the available busses in a parallel manner, combining incremental load across both the sine tracks and the associated busses. This is simulating a mix environment even more so than the PostLoad test.

For this series of testing, I concentrated purely on the SerialLoad test.

As is clearly displayed in the first screenshot with the session running @ 064 Buffer, the premise of the serial load landing and utilizing only a single core, is not applicable with Reaper, which assigns the processing across multiple cores. But only to the value of 1.0C total processing available?

Say what ?

The processing being displayed is not parallelization of the serial insert strip, more so a load spreading of the available resource of 1.0C ( a single core ) across multiple cores via thread management and Windows Task Scheduling. I covered this in depth in a series of reports around 2022, but reading back at those reports now, I have realized the relevance has shifted, if not been lost on the current DAW versions, as what was being displayed and reported on those earlier DAW versions on the previous CPU architectures, has changed. Needless to say the dots are constantly shifting. Better to stay focused on the current CPU architectures, and for this article on WoA. Having said that, I did have Justin Frankel explain the load spreading process on his 2^nd visit to the podcast for those that want to dive in deeper.

2^nd Screenshot is with the session fully loaded @ 512 Buffer, and it has moved the assignment of the processing to only the 2 primary cores , which were evident in the first screen, but the assignment across the other cores has been negated.

DAWbench DSP MIX/MIX-EXT

The DAWbench DSP MIX sessions were developed as a result of an investigation I initiated following up on a series of reports by a close knowledgeable friend who was experiencing odd threading and MP performance scaling on his Real World Mix sessions. The reports are quite detailed and too extensive to cover here, so for those that want to dive right down the rabbit hole, you can read the reports at my DAWbench FB page, but probably best to read them in better context as I summarized them on my GS thread Here , starting at post #1359.

There are 2 MIX sessions, the standard being an emulation of an exact mix session, using same number of tracks, groups, busses, FX sends, etc, and MIX-EXT, which is the same session but increasing the overall processing overhead across the tracks/busses, and also allowing scaling of additional plugins on the busses for the systems capable.

I call these sessions the deal breakers regards thread management and scaling, as in some DAW’s they can collapse the engines very prematurely.

Screenshot shows the MIX-EXT session pushed to break with additional Analog Obsession Frank CS Channel Strip plugins activated . Thread management and MP scaling is as close to perfect and as expected.

DAWbench VI K8P

Screenshot shows the new DAWbench VI 2025 Kontakt 8 Player version of the test with new sample sets , running @ 128 on the UCX , which was the lowest I was able to run the VI test on the RME. I was able to run the test @ 064 on the Steinberg UR22-C, at very similar latency between the respective settings across both interfaces, so the failure at 064 was more so the RME driver than the platform. This of course opens another area of investigation which I’ll cover in another report, that being the comparative performance of the audio interface drivers for WoA.

Session was stable, Scaling and Thread management was as expected, and I really couldn’t have asked for more, considering that Kontakt was running under emulation.

Cubase 14

DAWbench DSP-TUBA

As noted in the Reaper reports, this is the new standard DAWbench DSP multiprocessor saturation test that applies a progressive and incremental load horizontally across 80 tracks of audio. Thread management is more empirical than a RW session as each incremental plugin load is assigned sequentially per track in essentially an ideal wide/parallel fashion. It can still be useful to highlight respective DAW thread management and shows the dynamic of the respective audio engines in regards to scaling per buffer settings. With the Analog Obsession TUBA VST3 plugin using 4x Oversampling, it was interesting observing the difference in how the Cubase Audio Engine behaved as each plugin was activated in real time while playback was active.

Whereas Reaper’s playback remained gap-less at each instance being initialized, Cubase would stutter at each instance as the PDC routines were calculated in the back end. Yes, it’s a brutal test for a real time engine, but worth noting.

As with the Reaper, the screenshot of this session is running on the RME UCX @ 64, and delivered good MP scaling performance, tho it didn’t match Reaper in outright performance. There is one core that I suspect is being reserved for GUI, which could be a factor.

DAWbench DSP BUS-TUBA/Frank CS - SerialLoad

The screenshot is the SerialLoad session running fully loaded @ 512 Buffer, which shows a spattering of activity across some cores, but the vast majority landing and peaking one core. This is closer to what many would consider normal behavior for serial processing across a single channel. I will note that this current behavior is not consistent to previous versions of Cubase, which displayed a threading dynamic of load spreading across multiple cores more akin to Reaper. Steinberg are constantly shifting the dots with their thread management, its almost like Forest’s box of chocolates.

DAWbench DSP MIX/MIX-EXT

And here is the deal breaker on full display.

Screen is of the standard DSP MIX session that failed to playback at any buffer setting, needless to say there was no point even attempting the MIX-EXT version. Steinberg’s ASIO-Guard engine collapsed prematurely, thread management and assignment was all over the place compared to Reaper. This behavior is consistent to x86 as well BTW, so it’s not an issue with WoA and/or the emulated plugins.

Studio One 7

DAWbench DSP-TUBA

The new default DSP saturation test running on Studio One 7 @ 064 on the RME UCX, scaled and thread managed O.K , the engine being exhausted earlier than both Reaper and Cubase at this lower buffer setting, but overall no major red flags to report. Like Cubase the engine was not gap-less when activating the plugins due to the inherent plugin delay assigned to the 4 x oversampling.

DAWbench DSP BUS-TUBA/Frank CS – SerialLoad

This was interesting to see the processing predominantly load balanced across 2 cores like Reaper, which is a different behavior to what I observed in earlier versions on x86 , where the processing would predominantly load and peak a single core. Dots are shifting with some areas of thread management across multiple DAW’s it seems.

DAWbench DSP MIX

Studio One delivered a mixed bag with the 2 MIX sessions , top screen shot shows it successfully loading and playing back the standard DSP MIX session @ 512. Thread management was not overly consistent, but considering the complexity of the session with groups/busses/FX sends, it wasn’t a complete fail.

DAWbench DSP MIX-EXT

Once we moved to the heavier DSP-EXT session the engine was unable to cope with the additional load and failed to playback @ 512. This is the core session, no additional FrankCS plugins activated.

Sonar 25

O.K, onto the last DAW for this series of testing , Cakewalk’s new Sonar 25 release.

DAWbench DSP-TUBA

Sonar 25 running @ 064 on the RME UCX like the other DAW’s, difference being Sonar does not use a hybrid playback engine , so there are no hybrid/extended buffer settings on playback, the engine is running natively on the hardware buffer. Overall number of plugins achieved is lower, but expected. Thread management and scaling was stable and as expected.

DAWbench DSP BUS-TUBA/Frank CS – SerialLoad

I almost had to do a double take to make sure I was not looking at a Studio One screenshot by mistake, as the thread management again is predominantly across 2 cores, with a small spattering across some other cores. This seems to be a more common and widely used threading behavior across multiple DAW’s.

DAWbench DSP MIX

Sonar 25, like Studio One delivered a mixed bag with these 2 sessions , top screen shot shows it successfully loading and playing back the standard DSP MIX session @ 512. Thread management was very similar to Studio One. I do need to emphasize again, this engine is not running a hybrid or extended buffer , so its holding its own again by being able to run this session against for example, the Cubase engine that is running a heavily extended buffer with ASIO-Guard.

DAWbench DSP MIX-EXT

Like Studio One, once we moved to the heavier DSP-EXT session the engine was unable to cope with the additional load and failed to playback @512. Thread management and load balancing looked very even, so I suspect at a higher buffer it would have played back successfully.

Overall , I was impressed with the Sonar audio performance, especially with it being a non hybrid , native hardware buffer engine.

Summary and Conclusion

Although WoA is relatively still in its infancy for DAW application, and I wouldn’t yet recommend the platform as a sole mission critical solution, for mobile / live onsite application, even running under emulation, these laptop solutions could fit the bill, as long as you can successfully install and run the required plugins and VI’s. Anything requiring an iLok is a no go at the moment, and some plugins installers will not install natively, but as I noted in the article, could well work simply copying the .dll’s to the correct directory from a native x86 install. Not ideal, but I had no issue getting all of the required Plugins and Virtual Instruments installed and working for my DAWbench 2025 Suite of test sessions.

Comparative performance is something that I haven’t delved into this article, simply because the majority of the testing was done under emulation, so it really wouldn’t be a fair appraisal against the other platforms running natively. Even under emulation, I was getting some results around an Apple M1 era chip running natively, so potential is there.

The overall experience for me has been a huge positive, the laptop has been very stable under extreme loads, the noise level is pretty much non-existent unless pushed to the nth degree where the fans are forced on, and even then , it was around 20db. Nothing like the hair dryer level fan noise on x86 laptops of recent times. Battery life, no idea to be honest, as I don’t run heavy DAW applications on battery, but from feedback I have from trusted friends who have the same units, they will run all day on a charge under normal computing conditions.

So where to from here ?

Things are still progressing at a slow but steady rate regards native support for major audio application, one of the current larger hurdles is iLok, which is supposed to be completed by early next year. I believe after that is finalized, we could see a large rush of plugins being ported to WoA. For those that do not require iLok, its going to come down to available resources, weighed up against demand. Its kind of a chicken and egg situation in some respects, but we have been in the same position with things like Atmos support on Windows for example, which was initially being dismissed by Sony for professional Windows support, and then what started as a trickle, ended up as a rush, and now most major DAW’s support Atmos natively.

I do have some comparative DAW benchmark results across the respective DAW’s that I will knock up into a report in a future article. I am currently finishing up my DAWbench session ports to BitWig, so I will include those as well. I will also collate and create a Audio Interface Low Latency Performance Database for WoA to mirror my current x86 Windows Database.

Until then.

Apologies for being on radio silence around here of late, I haven’t forgotten the Cross Platform DAW Performance History / CPU Architecture War articles. Time and energy focus has been directed away from writing at the moment , but they are in the works.

Lots of work being done behind the scenes with both WoA and x86/AS development and testing, DAWbench DSP has been ported to 5 DAW's, with the BETA's in heavy rotation particularly in the WoA testing which I will report on shortly.

Pete from Scan has been in the front line doing some heavy lifting, also now including official Apple M4 in the results, only the baseline for now, but at least gives us a glimpse.

DAWbench VI has been shifted to K8 Player and Freeware libraries for easier access to testers, initially due to what we thought was the original K6 version falling over on AS. The results didn't move the needle that much if at all on K8, but details can be read in Pete's report.

https://www.scanproaudio.info/2025/08/05/dawbench-testing-2025-edition/

Stay tune, lots incoming over the next few months.

New Podcast Uploaded. :

Now across all of the major podcasting platforms.

DAWbench Radio Show : Episode 38

Music Tech Pioneers VI : Roger Linn – Linndrum to Linnstrument and Beyond !

A few links below, but easily found on most others with a search.

· Podcast Home Page : Here

· Apple Podcasts : Here

· Spotify : Here

Hosted by Vin Curigliano of AAVIM Technology, I am joined by guest co-host Pete Brown of Microsoft and special guest Roger Linn, who is the founder of Linn Electronics and is currently the owner and lead designer at Roger Linn Design.

We catch up again on what Pete and Chris have been up to since last show, get an overview of NAMM and Super Booth, Petes work on MIDI 2.0, WoA Dev, and the inbox Windows ASIO Driver, etc

We discuss Rogers early history with music and technology , and how that lead a path to founding Linn Electronics, the early days exploring electronics and creating tools to expand their usability, to his eventual development of the revolutionary LM-1 Digital Drum Machine.

We cover the subsequent instrument designs and evolution, the challenges of staying ahead of an ever increasing competitive market, the fall of the company and his work with other companies in the late 80's and 90's.

We also cover Rogers return to designing innovative hardware designs with his new company Roger Linn Designs in the 00's, his work with contributing to the development of MPE ( MIDI Polyphonic Expression), his ongoing work with continuing to develop innovative instrument designs, share some great history and behind the scenes stories, and much, much more.

Host & Guest Links :

AAVIM Technology : www.aavimt.com.au

DAWbench : www.dawbench.com

Microsoft : www.microsoft.com

Pete Brown : https://twitter.com/Pete_Brown

Link Audio : www.linkaudio.com.au

VO :

Andrew Peters : www.andrewpetersvo.com

Music Themes :

Original DAWbench VI Theme Music composed by Rob John : Independent Music Productions :

http://www.indmusicprods.com

DAWbench Radio Show ReMix by Erin McKimm : www.erinmckimm.com

All Rights Reserved : © AAVIMT 2025

New Podcast Uploaded. :

Now across all of the major podcasting platforms.

DAWbench Radio Show : Episode 37

TechBytes 10 : 2025 Music Technology Mid Year Review !

A few links below, but easily found on most others with a search.

• Podcast Home Page : Here

• Apple Podcasts : Here

• Spotify : Here

Hosted by Vin Curigliano of AAVIM Technology , I am joined by guest co-hosts Pete Brown of Microsoft and Chris Mann of Link Audio.

We catch up again on what Pete and Chris have been up to since last show, get an overview of NAMM and Super Booth, Petes work on MIDI 2.0, WoA Dev, and the inbox Windows ASIO Driver, etc

We do a general catch up and summary of the last 12 Months in DAWbench testing and development work. Revisit thread management on respective DAW’s, highlighting the additional curves being navigated due to the new Intel 15th Gen Ultra’s P/E core order layout throwing out previous core affinity assignments, etc.

We cover some of the major new DAW releases, and those leading the way in WoA native support for both software and hardware. We again revisit and discuss the ever evolving area of Emerging Tech involving AI Generative/Creative/Ethical. We discuss Atmos and Immersive Audio and how Apple Music is driving that area further into music outside of film/TV.

We discuss the ongoing CPU and Platform Wars covering Apple M4 Series vs x86 , detail Intel's new Ultra 200 Series CPU's and AMD's X3D CPU's, and discuss the Qualcomm Snapdragon X CPU platform, and its rapidly accelerating uptake and support for Music/Audio production.

We share some more stories from the Tech Support Trenches, and much more.

Host & Guest Links :

AAVIM Technology : www.aavimt.com.au

DAWbench : www.dawbench.com

Microsoft : www.microsoft.com

Pete Brown : https://twitter.com/Pete_Brown

Link Audio : www.linkaudio.com.au


VO :

Andrew Peters : www.andrewpetersvo.com

Music Themes :

Original DAWbench VI Theme Music composed by Rob John : Independent Music Productions :

http://www.indmusicprods.com

DAWbench Radio Show ReMix by Erin McKimm : www.erinmckimm.com

All Rights Reserved : © AAVIMT 2025

New Podcast Uploaded. :

Now across all of the major podcasting platforms.

DAWbench Radio Show : Episode 36

Honouring the Legendary : Bob Moog Foundation : Innovation, Inspiration, and Igniting Creativity !

A few links below, but easily found on most others with a search.

• Podcast Home Page : Here

• Apple Podcasts : Here

• Spotify : Here

" It's Moog, Rhymes with Vogue ! "

Hosted by Vin Curigliano of AAVIM Technology, I am joined by guest co-host Pete Brown of Microsoft, and special guest Michelle Moog-Koussa who is the founder and Executive Director of the Bob Moog Foundation , which she established in 2006 to honour the legacy of her father, Bob Moog , who is the legendary and revolutionary music tech pioneer that invented the first commercial analog synthesizer.

We discuss Bob Moog's early history first building and selling Theremins in his teens, and how that lead the path to developing the first series of voltage controlled modules that would eventually evolve into the Moog Modular Synthesizers. We cover the difficulty in first getting the instruments accepted , the paradigm shift in the late 60's and early 70's to a wider audience with the Wendy Carlos Switched on Back Album and other key artist using the instruments , and the development of the MiniMoog.

We detail the history of the company throughout its numerous stages and ownership's, Bob's loss of his trading name/trademark and eventual exit to found Big Briar. We discuss his tenure at Kurzweil, and subsequent innovations and developments throughout the 90's, leading back to the eventual reclaiming of his name in the early 2000's, and his return to creating synthesizers with the Moog Voyager.

We also discuss Michelle growing up as the daughter of Bob Moog, where she shares some great behind the scenes stories and memories of the man behind the legend, what inspired her to take the path of founding the Bob Moog Foundation, managing and maintaining the extensive historical archive, the Moogseum and the expanding educational programs.

We cover the support provided by industry partnerships with software developers, as well as also discussing how the Foundation is an independent non-profit , donor driven organisation, and detail several ways that people can get involved to support the Foundation, and much, much more.

Host & Guest Links :

AAVIM Technology : www.aavimt.com.au

DAWbench : www.dawbench.com

Microsoft : www.microsoft.com

Pete Brown : https://twitter.com/Pete_Brown

The Bob Moog Foundation : https://moogfoundation.org/

VO :

Andrew Peters : www.andrewpetersvo.com

Music Themes :

Original DAWbench VI Theme Music composed by Rob John : Independent Music Productions : http://www.indmusicprods.com

DAWbench Radio Show ReMix by Erin McKimm : www.erinmckimm.com

All Rights Reserved : © AAVIMT 2025

Picking up where I left off in Part 1, where I covered the 90’s and early 2000’s leading up to the paradigm shift of Apple moving to Intel in 2005, and the emerging Hackintosh era. Now before moving on from that point, it will be good to wind it back a bit and take a closer look at the actual transition, and place it into context with all the other chess pieces that were being moved around in the computer tech and DAW space at the time.

Mac OSX : 10.4 Tiger to 10.6 Snow Leopard

MacOS, formerly known as Mac OS X from 2002 to 2011, and then OS X till 2016, had navigated its way to version 10.4 Tiger ( April 2005 ) around the time of the Intel announcement, and would introduce some x86 support by the initial launch in early 2006. 10.5 Leopard (October 2007) was the version that had increased x86 support and would be the last to support PowerPC. This was the version I started my OSx86 ( Hackintosh) investigation on, and finally 10.6 (August 2009 ) was the first to be Intel-Only, and with full support for the Intel x86-64 architecture at kernel level. The last point is interesting in hindsight, as it explains the shift in performance I experienced and documented around that time moving from 10.5 to 10.6, and highlights to me just how guarded some of the finer details were to obtain back then.

Apple Intel x86 Transition : Timeline : The Journey Begins

An overview of the time line for the Apple Intel x86 transition is in order here, just to give some additional clarity.

1) June 2005 - The announcement was made at the WWDC.

2) January - July 2006 Apple announced and released numerous laptop/desktop models, initially with 32bit Core processors, which were then upgraded to 64bit Core 2 Processors as those CPU’s came online in July 2006.

3) August 2006 – Transition reported to be completed with the announcement and release of Xserve and Mac Pro’s using the Xeon 5100 series CPU’s.

So full transition in 14 months from the initial announcement, which was pretty good considering just how big a ship it was that they needed to turn around.

You may see a misalignment with hardware releases and full support at Operating System levels, but this was something that was glossed over and never really discussed, as the RDF being wielded by the marketing department was strong.

There were also some feverish Jedi Mind Tricks being played during this time, as there were sectors of the Apple Mac community that were not overjoyed with the transition, and saw the shift as akin to Apple sleeping with the enemy, and making a deal with the devil. For or those of us who were outside of, and not under the influence of the RDF, the question was more so - Who was actually the devil in this arrangement?

The MacHeads, as they affectionately called themselves – see Doco linked here for reference, (Trailer) (Full Movie), for the most part associated Intel with Wintel, the unholy alliance with Microsoft Windows that created a marriage made in Hell in their eyes. For me, the marriage of Intel to Microsoft hadn’t really diminished with this move, I saw Apple as simply now being a high maintenance mistress on the side, LOL!

Also the previous comparative performance charts regards DAW performance of Mac PowerPC v x86 Windows systems mysteriously disappeared into the depths of the RDF, replaced with flowing charts of just how much better the new Intel chips were performing against the older PowerPC chips. So Apple needed to up the anti and refocus their targeting away from their new partner, towards the remaining Evil Empire of Windows. After all, with essentially the same hardware, the only thing they could now leverage was that the OS was more efficient and higher performing for DAW application, right?

Microsoft didn’t really help there when they introduced Windows Vista, much to the delight of the Apple Marketing department, who used it as a catalyst for the – “I’m a Mac, I’m a PC “ series of ads , that went viral at the time. I’ll revisit that in more detail in the next section, where I cover the Windows / x86 platform landscape during this period of transition.

Windows 2000 (NT5) to Windows 7 (NT6.1)

On the operating system front, Windows development and usage in the late 90’s moving into the new millennium was split between the more widely used Windows 98, and the more advanced NT line which hadn’t grabbed the wider DAW user base due to the limited compatibility and availability of Professional audio applications. NT4 most notably had been used for higher end audio only systems like Pro Tools TDM, but wasn’t gaining the support of the other DAW’s that had more MIDI sequencer based origins. NT5 aka Windows 2000 or W2K, made some moves in that direction as it supported the potential to use multi processors systems for native processing, but was held back due to the legacy of NT having bad MIDI/Audio timing issues due to some hurdles being navigated due to NT’s abstraction layer between the hardware and O.S, which was slow at first. It was introduced to greatly reduce the problems introduced by bad hardware or drivers, to protect against hard crashes that were more susceptible on Win9x. These issues were thankfully resolved in the W2K life cycle, which laid the groundwork for a much wider adoption for Windows XP, aka NT5.1 in 2001.

Windows XP had a very successful run over its deployment life cycle, and also spawned a 64Bit version in XP Pro x64 (NT 5.2) in 2005, built on the Server 2003 x64 code base, with the package being tweaked for Workstation usage over Server. There was an earlier Windows 64Bit available in 2001, but that was specifically for the failed Intel Itanium 64Bit architecture, which I will cover later in this article.

Following XP and riding on the momentum achieved, Microsoft made the move to Windows Vista (NT6.0) in 2007, and this is where things started going a bit sideways, IMO. Vista was a major release being the first with the NT Version 6 nomenclature, and it had an extended, difficult and disjointed development cycle where features were being developed and then pulled due to various issues. Development started in 2001 and was scheduled to take 3 years, but was eventually released in 2007 with a subset of the original feature set. The list of changes that were still introduced are way too long to cover in this article, but for those interested, are detailed here.

Vista was not well received by the end user base, some of the main issues being navigated included a new signed kernel driver model that had made hardware compatibility more difficult, a new GUI and Visual Style called Aero which added significant features like transparency, but was quite demanding on required resources, and a new security feature called User Account Control. The later many felt was overly intrusive, as in its standard configuration would essentially ask you if it was safe to move forward with any installation, setting change, etc.Vista was also viewed as being overly bloated and lethargic in comparison to XP, and due to the fact that XP was still available and being fully supported, a large sector of the end user base crossed their arms and rejected the O.S. Windows users, unlike Apple users, had a choice of which version of the O.S they chose to run on the latest hardware.

Apple marketing took the compliant of bloat and being overly intrusive, amplified them 100 fold, and mocked them brutally in the “I’m a Mac, I’m a PC” ad campaign I noted earlier. The fact that a lot of the new features that drew the most complaint could be dialed back, disabled and/or easily managed by the end users made no difference, the horse had bolted. For those of us used to the more streamline simplicity of XP, it was quite a departure, and for me, an unnecessary and misguided one. For audio application, Microsoft had introduced features like WASAPI, Wave RT and MMCSS ( Multimedia Class Scheduler Service ), which were features that found various level of acceptance and usage over the following years, but outside of the scope of this article.

For Pro Audio and DAW usage, I found even with extended tweaking that Vista offered no advantage over XP/XP x64, so I simply leap frogged it to Windows 7 (NT6.1) in 2009. Microsoft thankfully had read the room and listened to the end user feedback, as well as taking note of the non-acceptance, and came back with a more streamlined and optimized revision that was focused on performance, which of course rang all the right bells for those of us that had rejected the direction that Vista had taken. Windows 7 was a huge success, well comparatively to Vista, and hit the ground running, gaining huge end user support and acceptance.

For this article I will stop there regards Windows version, as XP-Win7 covers the period of Cross Platform Performance I will be focusing on in this first series of articles.

Intel, AMD – The Road to x86-64

During the period leading up to the Apple Intel transition, the PC x86 Hardware side of the aisle was navigating its own dips and curves. Intel had moved from its more streamlined Pentium III P6 based architecture to the new Netburst architecture for its 1st Gen PIV – Willamette (2000), which was a significant change in architecture and core execution, using a much longer instruction pipeline and requiring higher clock speeds to complete the instructions. This played well from the position of marketing if all that was being focused on was clock speed, but the fact was that it required far higher clock speeds to compete with AMD’s Athlons CPU’s of the time, as well as even their own PIII architecture. The later lived on in a lesser known variant called the PIII-S Tualatin, which was a server based processor with larger cache and improved execution, that also had increased clock up to 1.4GHZ. I used PIII-S chips extensively in the early 2000’s DAW solutions I was building and deploying to clients at the time.

Intel however was all in on the PIV Netburst architecture, the PIII-S’s disappeared, and the initial plan for Netburst was to reach clock speeds of 10GHZ, which didn’t happen. Clock speeds stalled under 4GHZ after 4 generations, the last being Cedar Mill released in early 2006, pipelines were being extended even further to achieve those higher clock speeds, and the thermal envelopes were going through the roof. Add to that, Intel were beaten to the punch by AMD to a dual core and essentially glued together two PIV’s and called it a Pentium D to attempt to compete. Intel were also forced to implement the AMD developed x86-64 (also known as AMD64) 64bit instruction extensions, despite spending billions on developing and attempting to introduce a wider acceptance of their Itanium IA64Bit platform. The writing was on the wall for Netburst, Itanium IA64 had already failed to move the needle regards penetrating any market except for higher-end enterprise server, and considering Apple had announced that they had committed to a transition to Intel x86, more than a few in the industry were wondering WTF were Apple actually going to be shoe horning into the new Intel Macs ?

The devil is in the details of course, because Apple obviously were privy to the Intel roadmap of what was incoming. At Intel there was an alternate architecture that was being developed side by side with Netburst by a separate development team. This development became the foundation for the future Core line of processors that were to be deployed by Apple. The architecture was a branch of the mobile Pentium M line of processors, which itself was based on a significantly enhanced version of the P6 architecture. Due to its P6 heritage, the new Core architecture had a much shorter instruction pipeline than Netburst, coupled with far higher IPC ( Instructions Per Clock). The result being it required less clock speed to complete the instruction execution, and was subsequently using far less power. The last point would be a significant factor for the Apple hierarchy. I’ll cycle back to detail the Core releases later, as we complete the cycle of transition.

AMD at the time was riding a wave of achieving higher performance at lower clock speeds due to maintaining an architecture with shorter instruction pipelines and higher IPC, so although they may have been losing in the marketing department focused on clock speeds, aka the Megahertz War, often referred to then as the MegaHurts War, they were doing quite well regards comparative performance against the Netburst PIV/Xeon variants with their K7/K8 Athlon and Opteron Processor lines, which spanned 1999-2006.

The K7 Athlon (1999-2001) / Athlon XP (2001-2003) ranges were the first products from AMD that took the fight to Intel in terms of outright performance, the initial Athlon was the first chip to 1GHZ, winning the first round of the Megahertz War against the Pentium III, and the Athlon XP lined up against Intels PIV. Grading CPU’s purely on clock speed had become more complicated due to the Netburst architecture needing inflated clocks to deliver the same performance, so AMD marketing at the time then came up with a PR ( Performance Rating ). This rating designated that the lower clocked CPU’s were comparable to Intel CPU’s at a higher clock, i.e An Athlon XP 2020Mhz Chip was PR at 3200+, designating it would equal the performance of a PIV at 3.2+GHZ.

The K8 Athlon 64 (2003-2006) was very similar to the K7 except that it introduced two significant changes. It was the first chip to implement the X86-64 64bit extension to the instruction set, and it also featured an on-die memory controller, which greatly reduced memory latency and was largely responsible for the performance improvements over its predecessor. The later Athlon 64 X2 was the first Dual Core desktop processor, whose performance was significantly higher than Intel’s cobbled together Pentium D. The K8 Series of processors also introduced the Opteron line of Server/Workstation processors that were widely adopted through a very aggressive promotional campaign by AMD into the Pro Audio community.

The Opteron’s found their way into individual’s hands and studios using the higher end native DAW applications of the time, like Nuendo, giving the end users the first foray into systems offering 4 processors when running Dual Dual Core configurations. They weren’t without their teething problems and curves though. Compatibility with audio hardware, both interface and DSP cards , was at times very difficult depending on combination, and they also had an Achilles heel when being used in heavier native DSP sessions, where audio streaming/playback would break down prematurely at anything above a 60% CPU load under certain session logistics. Despite the above, both the Athlon 64 X2 and Opteron’s found a strong following in the Professional Windows PC arena, and were at the time leading into the Apple Intel transition, the superior chip. So it wasn’t hard to see or understand why the rumors of a possible team up between Apple and AMD were being fermented.

The script was about to flip though, when Intel released the original Core series (January 2006), and even more so the 64bit Core 2 line of Processors in July 2006. The latter featured EM6T4 ( Intel Extended 64 Memory Technology), essentially a slightly tweaked and renamed version of the AMD x86-64 extension, that had been renamed AMD64. Note the release dates, as they coincided perfectly with Apples Intel release timeline, which was by no accident, as the mistress was I suspect in some respect, coordinating if not gently coercing those release times with Intel.

Core 2 and the Xeon derivatives were the paradigm shift not only for Apple, but also for Intel who desperately needed a response to AMD at the time, and to put the whole Netburst saga behind them. Core 2 delivered substantial improvements in architectural efficiency due to its shortened pipeline, high IPC and OOO ( Out Of Order) execution routines, that saw it easily outperform its PIV predecessor at far lower clock speeds and power consumption, which is what inevitably drew Apple to the Intel camp. The Core 2 chips released Dual and Quad Core versions over a few generations, which gave the Pro Audio community access to high performing systems of up to 8 cores when used in dual cpu configurations, on both Mac and Windows PC platforms. We were entering a golden age of accessible native DAW performance, which was unreachable a short few years before.

To give an example of the performance uplifts achieved in DAW application benchmarks I had developed, the Core 2 Duo on release delivered around a 40-60% improvement over the previous PIV chips at clock speeds around 2.4GHz, to say it floored me was an understatement. The Core 2 Quads on release elevated that again to levels that were unavailable even in dual CPU configurations.

Intel followed up the Core 2 line with the Core i Series (2008), which brought with it an integrated 3 channel memory controller, Quickpath interconnect and the return of Hyperthreading, which unlike its earlier incarnation on the Netburst architecture, gave a more consistent boost in threading performance. This is the platform that was the core of my adventure into the cross platform head to head testing which I will outline in the next article.

Before I close off I do need to return to AMD’s response to the Intel Core juggernaut that delivered performance way above anyone was expecting at the time, least of all AMD, who IMO were completely blindsided. AMD at the time, at best held single-figure advantage over the Intels, so it wiped them off the playing field in one fell swoop. They needed to respond, and AMD’s response was the K10 (2007) architecture, in both Phenom x4 and Operton derivatives which delivered incremental improvements over the previous gen AMD offerings, but were not able to catch or match the competing Intel chips regards performance. This was the start of an extended period where AMD would not challenge Intel for another decade.

My memory of the time around 2007-2009 was more so of relative calm, or maybe comparative calm, when it came to platform/chip wars. I had 2 Core 2 based development systems, Quad and Dual Quad that I was doing a stack of comparative performance testing on, focusing on Windows DAW performance. The Intel v AMD online battleground had been extinguished, while Intel had embedded itself with Apple, and for the most part, things were just moving forward re incremental performance improvements across hardware/applications.

There were still the occasional squabbles over OS/Platform superiority, but it was the calm before the storm, because things were about to heat up as the OSX86/Hackintosh arena ramped up, pitting MacHeads vs Hackintosh interlopers on their own side using open hardware, and of course I stepped into the middle of that looming minefield with my own i-Series Hackintosh dev system, to further shake a few apples free from the fruit trees.

Next Up : Part 3 : Let The Battle Begin : Round 1 : Head to Head on an Open Platform !