I am Hydlide of ReasonExperts. Today I just to want to get a few lines off my chest because of a struggle I am dealing with when it comes to fully use my I9 - 14 core processor and using this in combination with Reason. Before I want to get started I just want to get a few things down first (just to take away a few vague assumptions).
1. There is something really wrong with the core distribution when it comes to Propellerhead Reason
2. There is something really wrong with the thread distribution when it comes to Propellerhead Reason
3. There is something wrong with the Reason Engine.dll file
4. There is something wrong with people using DSP as a counter argument
5. The VST implementation is not optimal
Now... that I got this out of the way, let's move on. The core problem is something I can not address in its current state. Since posting the core problem in the public means that my EULA would get revoked (meaning, I could not use Reason as a DAW anymore, the same thing could be said about Ableton). But since I have located parts of the problem (which is not DSP related directly, but has an impact on how it is handled). So I am trying to make this article as politically correct as I can be without having to get sued, nor get my license revoked. The parts I am going to show are going to be technical of nature. I am using existing pieces of software to analyze data (which can be done without breaking the EULA) while I am not going too much in depth about it (since there is more it than this). I did a thorough investigation to pinpoint some parts on where the problem is located at. To best test case the different DAWs and their relationship I used the following test case scenario to benchmark three different DAWs: Studio One 4, Ableton Live 10 and Reason 10.2.
This test case was done after my initial discovery on how Multi-Core processing is handled using Reason 10. I have notified the HQ, but haven't got any response about this back. So I am throwing this out in the open now (it is nothing new anyway). The initial post I made was posted on youtube:
Initially, I had Hyperthreading turned on while making this video. And this made things even worse. But the same scenario is quite applicable when using multi-core only yet turn HyperThreading off. The following screenshot was taken while using ProcessExplorer. A tool that was developed to analyze what processes are captured (kind of like an advanced Taskmanager)
in this screenshot, you can see that all cores are using the exact same amount of CPU. This is what I would call the Thundering Horde approach to spin up threads. More about this one
Understanding Threads and multi-core
Before I am going too much in depth about my findings. Let's start with the idea of threads, multi-threading, hyperthreading, and multi-core. Because these are 4 different things.
A thread is an instance of a service or worker. It is the solo to process information. A thread can be used to call other threads. Or it could be an invoker for being an observer of a multi-threaded processor multi-core process. As you can see, a thread is a master of doing things. And yes, this gets technical.
Multi-threading comes in two different forms. Multithreading is a technique developed by AMD to handle different threads while using the CPU functionality. A multi-threaded application is run by a single thread where this single thread monitors the states of different threads and sends them instructions to do. The latter is a programmatic solution. While the first is sorted on CPU level.
Hyperthreading is a technique which is developed by Intel. It is meant for splitting up a Core into two. So one core consists of 2 hyperthreading processors. If the main core gets too much stuff to handle, the main core can pass on instructions to the hyperthreading core. This would normally be used to drop the load on the main core.
Multi-core processing is a technique where one master core sends out instructions to different cores. These days the operating system can have a large impact on how multi-core is handled. Some software uses multi-core processing effective to do certain tasks faster (such as rendering programs).
While hyperthreading and multithreading were 'supported' since Reason 8 (I could be mistaken about the version number) it already started with a rocky start. The problem was that hyperthreading caused more CPU overload, rather than to fix the CPU load. Even better yet, with my current setup Hyperthreading causes an increase of 20% on Reason itself (where Ableton Live does not). It seemed logical to me when looking into the issue that the hyperthreading support back then was better in Ableton Live than in Reason. And since this article is all about that, I will probably use this phrase a lot in here.
When Multi-core support came later this resulted in no issue at first. Since well... we were all using 4 cores eventually. So it wouldn't get any notice. From some angle, I have overheard that I9 processors are not on the radar of Propellerhead HQ (I got this information online). To be honest, it would not come as a surprise that an I9 would not be on the radar for development purposes because these things are pretty new (a year old by now), and these things have a pretty high price tag to develop things on to. So from that angle, it makes perfect sense that I9 processors are not on the scope of Propellerhead.
I tried to contact them about the issue and showing my results. By the time you read this line, you know what the answer is (being politically correct now).
Multi-thread support had the intent here with Reason to push all the data equal to all processors (cores) at the same time. While at first, this isn't a problem. Once you start using more cores, then it will be (insert green frog here).
Multi-core support Reason VS Ableton
I have read a lot of different stories about multicore support and how this has an influence on DSP, Latency and the works. You name it. Therefore, I am going to call this the Reason VS Ableton paragraph because everyone can throw their theories away. And yes I know the VST implementation of Reason isn't perfect. But by the time they have perfected their VST code, this issue will still remain the same (trust me, I will get back with that one once that release has been made).
The difference between Ableton and Reason is that Ableton Live uses a Turtle approach on how to deal with threads. While Reason does the thundering horde method. These are two different methods of developing (for instance a high traffic site). The turtle method is a way you start slow first, wait until you reach a specific threshold and once that threshold is met, you call in reinforcements. The thundering horde method is that you require as many resources you can get at the first go you press a key on the keyboard.
These are two different styles on developing an application. Now what is even more interesting to say here (in this context) is that Ableton Live borrows their DSP from what is known the Ucrt library (system 32 in windows that is), while Propellerhead Reason uses its own custom brewed "Reason Engine". While at first brewing your own engine is smart, but in the end, it comes with a price. And I believe Ableton quite understood this since now they are making full use of the WASAPI that came originally with Windows 7 (later totally supported with Windows 10). The WASAPI is a part of the HAL (Hardware Architecture Layer) library that replaces ASIO btw (so you know what the differences are).
Propellerhead Reason, on the other hand, is still leaning towards the DirectSound drivers (from DirectX) with the additional support of Asio (which is not ideal on Windows 10 machines anyway).
The difference here is once you start analyzing threads and their increases, it is quite shocking once using them per duplicated device. Where reason doubles the resources (amount of threads), Ableton does not. The problem that we will be facing eventually is when using too many instances the CPU gets clogged up and the DSP goes down the drain (because the CPU can't handle the number of instructions anymore in a timely fashion way).
Now, to be honest, I already had this issue since Reason 5. Since Reason 5 was a single core application with poor Hyperthreading capabilities. Now that we actually have the options to enable and disable Hyperthreading and MultiCore support, it has rendered things worse. The basic question is why is this?
The issue with Reason and its MultiCore support
Part of the problem lies in the way that multi-core support is simply handled in its current state. While normally you won't see any issue there. But once you start throwing 14 cores at this DAW, in particular, you will see the trend that all threads and processes are distributed equally. Not just with a single instance of Expanse (as I have demonstrated with the video as above) but ALWAYS! When you look upon how Ableton handles this, it is a different story. It uses a single processor to handle most of the traffic. And when traffic increases it starts to distribute the load over different cores/threads. This happens when using the same VST over and over again. And this happens when using different instances combined together.
The threads used by Ableton are in this case the UCRTBase threads. The WinMM part is the part that processes the audio and sends this to the soundcard (which is similar to the AudioCardLib process in Reason itself). Notice how the differences are which each instance vs the number of instances is used with the Reason Engine.DLL. Also make note that Reason Engine is running here because it runs Reason in slave mode (single instance btw, that might explain a few issues why rewire isn't optimal!)
To compare the differences between threads I did the same test case scenario for every DAW:
- load up the DAW
- choose Voicemeeter ASIO as my primary driver (so the comparison would be the same)
- load up Reaktor 6
- select Eliana (default patch)
- run it
- benchmark it
Now from this point on, I know what a lot of you Reason fanboys are going to say to me right now. But Reaktor 6 is a VST! And VST support is not fully optimized. True... But here is the thing though, I have encountered the same issue while messing around with multiple instances of Thor, Europa, and Expanse. The idea remains the same since the CPU gets distributed equally. And because this is simply the case, DSP gets influenced by the CPU. Thus we have an issue while using Propellerhead Reason and not being able to use the full potential of our hardware.
Additionally, I can say the I have found different fragments out there (which I won't post here, just because of the EULA). But I can say, there are some serious issues with the Reason Engine.dll file when it comes to Windows 7 (and especially Windows 10 users). In the end how I have figured this out will still remain a total mystery for you guys. But one thing I do know now is that the DSP isn't caused by the way DSP is handled. It is caused by the way Reason handles it. Here is a hint. Unit test ;)
When it comes to the way Reason is handling Threads and multi-core support in its current state. It is handled pretty poorly from where I sit at. And to be honest, I could make this post rather deep talking about opcodes. But I thought I would just keep out the geeky nerdy stuff. Because most people look at it from their DSP perspective, yet do not look at the core of what the DAW is doing. And this is what I have been doing in the last 2 months. So I know exactly why things are failing right about now from a multicore/hyperthreading perspective. The only problem here, I can't post my findings. Because... reasons (EULA). And while making this article, my license might be on the line even while posting this. But I thought I would just take a leap of faith. Look at it from a technical point of view, and see what happens with it. Maybe 'they' might change their minds.
I might eventually fully publish my findings. But this all depends if I get some form approval to do so. But from where I stand, there is more than meets the eye and there is more to it then you know ;)
This is Hydlide signing off
Written by hydlide