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 Coress, 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 3rd 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 3rd 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 2nd 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 3rd 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, which is the lowest latency we test the reference RME USB2 driver. Win/Win !
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 2nd visit to the podcast for those that want to dive in deeper.
2nd 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 ASIOGuard 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 ASIOGuard.
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.