[split] Windows GDI/realtime performance

[johne53]

new pc build,
AMD Ryzen 7 1700x CPU 8core, 16 thread 3.5G
16gb 3000mhz Corsair RAM
Samsung SSDs for system and projects

On MB32c I could actually run more channels and plugs with my old pc :O

Just out of interest... did your old PC also use an AMD processor or was it Intel?

[PascalC]

an interesting thread on gearslutz.

https://www.gearslutz.com/board/avid-pro...-tips.html

[vicenzajay]

an interesting thread on gearslutz.

https://www.gearslutz.com/board/avid-pro...-tips.html

Thanks for this - great info on that thead. I especially noted the posts at the end tracing the issue directly to (in this case) Pro-tools coding. I suspect that is why Reaper kills it in this arena - by coding such that affinity/priority hacks aren't necessary.

[vicenzajay]

an interesting thread on gearslutz.

https://www.gearslutz.com/board/avid-pro...-tips.html

@PascalC - quoting this again because the information on that thread just *might* have alleviated the issues.

On the older/recording computer (AMD 1090T/16gb/SSD), which primarily connects to Antelope interfaces through USB(2), I did exactly what was suggested. Launched the program, then set affinity within Task Manager to cores-minus-one (i.e. one core reserved for system, five assigned to Mixbus), and set process priority to "high".

Mixbus played projects perfectly (through hardware/hybrid mixing path - using a few plugs and compressor/eq being enabled on most channels and mixbusses). No spikes/dropouts/underruns/etc.! DSP usage stayed very stable at approximately 31-35% for the session. This was very encouraging.

So I moved to the primary mixing computer (AMD FX8350/32gb/SSD), which connects through the RME UFX+ - the flagship interface for RME - through USB(3). Doing what was suggested on the Gearslutz thread with either 1 or 2 cores reserved for system use did *not fix the issues. In fact, they were worse. I then bumped buffer settings to 1024 samples - and it didn't help at all (even worse - go figure).

So I then went back to 2 cores reserved for system use and 6 cores enabled (affinity setting) for Mixbus use. I also reverted to a 512 samples buffer setting. I then set priority for the Mixbus process in Task Manager to "realtime". This is the highest available priority for process priority, of course.

Perfect. No spikes, no issues. Fairly solid DSP reported by MB around 31-32%. Note that the mixing computer has UAD Octo and Quad PCIe cards/software - so I'm assuming (as that's the only real difference other than USB2 vs. USB3 for the interfaces' protocols) that this might be what requires the higher process priority for this machine.

Something to note (for the Mixbus developers) is that changing the preferences setting for CPU usage (first item in the settings dialog window) results in no change within task manager for actual processor core enabling. Each time I went to view/change those settings in Task Manager, every core was enabled no matter what setting I selected in Mixbus. I think it is fairly clear that some general work needs to be done within Mixbus' coding for CPU core usage and thread priority - not least of which is making it actually efficacious such that the settings selected cause the operating system to really change process settings.

Anyway - I'm *really hoping this solution continues to be reliable, as it just might allow me to shift primary mixing duties to Mixbus more permanently. Really helpful thread link and post, PascalC....I've been looking for such a solution for a month or more at this point. Thank you!

[Tassy]

Core unpark may also help. There are little apps to do that

[vicenzajay]

Core unpark may also help. There are little apps to do that

Sure - but you can do most of that directly in the BIOS options - which I've done for years.

I'm just really (cautiously) excited about the affinity/priority settings approach as it might be just what the AMD/Windows/NVidia folks need to run MB without these annoying niggles. I also think it (the thread/solutions) point out areas where MB can be improved under the hood for Windows users.

I adapted the batch (.bat) file on that thread for my two machines so that after launching Mixbus, I can just double-click it for a quick CPU tweak before going to work.

[johne53]

Launched the program, then set affinity within Task Manager to cores-minus-one (i.e. one core reserved for system, five assigned to Mixbus), and set process priority to "high".

Mixbus played projects perfectly (through hardware/hybrid mixing path - using a few plugs and compressor/eq being enabled on most channels and mixbusses). No spikes/dropouts/underruns/etc.! DSP usage stayed very stable at approximately 31-35% for the session. This was very encouraging.

So I moved to the primary mixing computer (AMD FX8350/32gb/SSD), which connects through the RME UFX+ - the flagship interface for RME - through USB(3). Doing what was suggested on the Gearslutz thread with either 1 or 2 cores reserved for system use did *not fix the issues. In fact, they were worse.

Yes, I once experimented with those settings and found they could sometimes make things better or sometimes worse. The other downside is that they're only temporary. Next time you launch MB it'll be back to its old settings...

[vicenzajay]

Launched the program, then set affinity within Task Manager to cores-minus-one (i.e. one core reserved for system, five assigned to Mixbus), and set process priority to "high".

Mixbus played projects perfectly (through hardware/hybrid mixing path - using a few plugs and compressor/eq being enabled on most channels and mixbusses). No spikes/dropouts/underruns/etc.! DSP usage stayed very stable at approximately 31-35% for the session. This was very encouraging.

So I moved to the primary mixing computer (AMD FX8350/32gb/SSD), which connects through the RME UFX+ - the flagship interface for RME - through USB(3). Doing what was suggested on the Gearslutz thread with either 1 or 2 cores reserved for system use did *not fix the issues. In fact, they were worse.

Yes, I once experimented with those settings and found they could sometimes make things better or sometimes worse. The other downside is that they're only temporary. Next time you launch MB it'll be back to its old settings...

Yep - that's why I did the batch files. I can launch Mixbus, quickly double-click the .bat file, and the settings are loaded for that session. Yet note that these are options/settings that should be selectable and efficacious within Mixbus! Other DAWs do this - in their settings menus you can select a process priority setting that actually interfaces with the operating system to adjust the process priority. This would, if implemented, negate the need to do system-level tweaks in Task Manager every time the program is launched.

So an update. I've decided to have both the machines set priority for the Mixbus process to realtime. There were still a couple of DSP underruns on the machine set to "high". At this point, the solution is fairly workable. Reserving a core or two for system use should, in theory, mitigate any risk incurred by locking Mixbus into the highest priority.

That said, I can "force" underruns and the occasional click/pop by moving graphics elements within Mixbus while working. If, for instance, you resize the mixbus portion of the mixer or even use scroll bars to get to hidden tracks, there is a chance that the DSP will spike to 80+ percent. Often that has no audible effect; however, from time to time it is causing an audible error.

So - earlier in this thread there is a good discussion of the graphics protocol used in MB...and it's problematic nature at times. I think (anecdotally - given the fact that I cannot test a large number of windows machines here at home) that there is merit to that suggestion. The graphics piece is causing a noticeable (and sometimes audible) effect on sound processing - which is another indication of an area in which opportunities exist to improve MB under the hood (for Windows, at least).

[johne53]

note that these are options/settings that should be selectable and efficacious within Mixbus! Other DAWs do this - in their settings menus you can select a process priority setting that actually interfaces with the operating system to adjust the process priority.

I must admit I don't have much experience with priorities but I've investigated the affinity settings in quite some depth. In the case of affinities (and maybe priorities too) it's important to be aware that any adjustments you make are purely "advisory" - i.e. Windows is free to ignore your requests if it thinks it can do better (or if it thinks they'll interfere with some other running app).

Modern OS's are multitasking and need to handle multiple programs simultaneously. And as such, they can't prioritise one app if it'll end up causing problems for all the others.

[SazzSomewhere]

I had some looks on the Ardour code base which should give some hints how MB is working. Most likely that there are some OS specific tweaks and additions from the MB developer team on a private repository but I would expect that there are no general architectural changes (otherwise the changes would have made their way back to the upstream Ardour code base). I expect that the main architecture works the same on Windows, Linux and MacOS.

AFAIK the primary development for Ardour back then was (and still is) Linux. Some years later Windows was introduced as an additional binary target but still as a second class citizen. In the early days the official way to build the Windows executables was to use Linux as the development platform and cross compile to build Windows binaries.

Please note that this was the state before Harrison stepped into the game. Most likely the primary platform for the MB development team has changed to Windows as most professional audio users are working on Windows or MacOS.

This is important to mention as the primary development target dictates normally for which the software is best optimized. And If you understand the history of a software, you can get a much better understanding of how the software will operate on a specific platform.

Cubase and Reaper for example were developed specifically for Windows. Therefore they integrate very well as a Windows application, uses appropriate APIs and can be therefore considered stable. Ok, Cubase is such a feature packed beast - Cubase is stable as it can get ;-)

Maintaining different platforms is a very time consuming task - either you write your software with inter-platform capability and make strong software decisions in the beginning. Or you have to invest a lot of man power to make a software for a different platform comfortable.

Ardour has none of them. It's open source software originally written for Linux solely. If you start from Linux, OS X integration is not that difficult as their OS works pretty similar (MacOS is still BSD Unix). But the API design of Windows is far away, some bits are still compatible with POSIX (Unix Standard), but this is mostly related to basic functions. For most libraries (like the Cairo drawing libraries) there are compatibility layers for Windows. But we are talking about >15 years of development. Typically people fix or extend the libraries to solve a specific problem. If the problem is solved, the code is not updated (till someone else has a problem ;-) )

I think the MB development team is doing a tremendous job to bring the Mixbus to Linux, OS X and Windows. But the history and complexity of Ardour takes it toll and I personally think that we will have to wait a good chunk of time till Mixbus will behave on Windows as performant as on Linux or OS X.

P.S.: If any developer of Mixbus read this - please consider OpenGL backend for Windows or something else as GDI bitblt's are really making it a horrible time when running realtime applications.