[split] Windows GDI/realtime performance

[SazzSomewhere]

I tested the setup on i9-9900k and Gigabyte Designare Motherboard and got nearly the same results.

I then installed a hackintosh and the issues went away - I could run 4x-6x more tracks without hitting the buffer.

Ardour/Mixbus is using the cairo graphics library for painting the GUI. Using Linux and Mac OS the library works well but in Windows the library uses stone age old GDI win32 interface which was invented back in Windows XP and is long superseeded with more performant interfaces like Direct2D, OpenGL, etc.

And as graphic cards driver are no longer optimized to handle the GDI interface this could be a possible show stopper.

My assumption is that due to calling the old GDI interface Windows internally has to do expensive context switches due to backward compatibility and therefore the timing gets messed up.

[vicenzajay]

I tested the setup on i9-9900k and Gigabyte Designare Motherboard and got nearly the same results.

I then installed a hackintosh and the issues went away - I could run 4x-6x more tracks without hitting the buffer.

Ardour/Mixbus is using the cairo graphics library for painting the GUI. Using Linux and Mac OS the library works well but in Windows the library uses stone age old GDI win32 interface which was invented back in Windows XP and is long superseeded with more performant interfaces like Direct2D, OpenGL, etc.

And as graphic cards driver are no longer optimized to handle the GDI interface this could be a possible show stopper.

My assumption is that due to calling the old GDI interface Windows internally has to do expensive context switches due to backward compatibility and therefore the timing gets messed up.

This is really good info - I will say that a few other DAWs (allowing for the fact that they are not DSP-heavy in initial loading requirement) have really concentrated on maximizing CPU usage/thread optimization to a point where Mixbus will probably need to step up the "game" to become mainstream. I'm still new with Mixbus - and I like it a lot - but I think I'm going to have to put it on the back-burner for actual studio projects. I can't be real-time bouncing a mixed project through hardware and have a DSP spike from 40-90 percent ruin the bounce 3/4 of the way through the track. I also shouldn't have to increase latency above 1024 samples on a project with 12 tracks and 10 plugins to be rock-solid during that bounce - even if 5 of those plugins are UAD products.

Hopefully this is something the developers can prioritize going forward.

[SazzSomewhere]

Personally I would say that currently Mixbus 32C is not usable on Windows.

I'm running a multi monitor setup. Just try to open the application, enlarge it to fill up the space of two monitors (2x 3440x1440), add 40 tracks and switch to mixer.

Then try to reduce the space of the left overview panel: It will take up to seconds to react. Or try the enlarge the space of the mixbusses. Same issue.

Using Mac OS I get easily to buffer sizes of 128. For Windows I get even for 1024 overruns. Same machine and hardware.

But maybe Harrison can step in and tell us whether they are going to fix the issues anytime near in Windows. Otherwise maybe they simply should stop selling on Windows platforms. Because selling a software on Windows which still uses the GDI interface is simply worthless.

I really would love to use Mixbus as a central component in my studio. But investing thousands of Euros for obsolete Apple Hardware just to have Mixbus is a no-go.

How about using the OpenGL interface as a backend for Cairo? There are already patches for that on Stackoverflow.

[Tassy]

As I investigate and see now, thousands of windows issues with MB is not the fault of MB and not the fault of windows but the poor communication between them! A lot background programs, openGL, gcc, VC++xxx ...and god knows how many and what other runtime library elements, that would be needed for MB to run well, are simply missing, not installed.
Poor windows tries to find some substituting something installed on the different PCs all around the world by other softwares, but all the random, non-recreatable issues are due to this lack of the program and the nonprofessional setup.exe.

Harrison should go back to the basics to find, list and install, together with MB, all what is needed to make windows understand what MB wants it to perform. And if necessary, I think it is, to change some of the MB programming to get rid of the huge number of and ever increasing number of strange, random issues that no one can solve though doing all his might.
Tassy

[SazzSomewhere]

Further reading about cairo issues on Windows:

https://stackoverflow.com/questions/2507...in-windows
https://stackoverflow.com/questions/3627...gl-windows

Ardour is primarily developed in Linux with Windows as an add-on. So you get out-of-dated glue code. Activities on Cairo for Windows? Simply none. There were some discussions of moving the Windows backend from GDI to OpenGL or even DirectX. This was still in the lights as Firefox used cairo as it's native rendering backend. But Firefox moved on and efforts were put on hold.

[Ben@Harrison]

@Tassy: I'm sorry, I disagree with your comments&solution. Mixbus (like many windows apps) provides our own .dll libraries rather than depend on anything on the system. This avoids the old "DLL Hell" that plagued windows applications for many years.

@SazzSomewhere: I think you've found some 9-year-old reports to back up your opinion. It is true that cairo could be improved on windows; however it is still demonstrably better than some other libraries we've tried. We "cache" our mixer-widget backgrounds, for example, so we can render them quickly with a bit-blit. If your system is taking 0.5 seconds to render a button, then it indicates a deep incompatibility in your system. Unfortunately it's not always possible for a user to troubleshoot those issues.

With the infinite variety of Windows systems, we can't guarantee that every setup will work perfectly. We've all had frustrating experiences with software, and Mixbus is not immune. But I get several nice comments from Windows users every day; I'm very happy with our current support & performance.

Mixbus works on Mac, Windows, and Linux; and I use all 3 regularly. I'd summarize the experience like this:

Mac: "just works" for almost everybody.
Windows: probably works great, but if it doesn't work then you have no idea how to fix it.
Linux: might not work at first, but if you know enough, you can make it work.

(this is not just for Mixbus, but for many applications.....)

That's just my $0.02

-Ben

[SazzSomewhere]

Dear Ben

maybe we have some misunderstanding here. I'm not talking about 500ms to render a button. If once the application window is enlarged, the channel strips reacts fast and smooth. But resizing the mixbus pane takes several seconds. The issue can be recreated on several different system setups running Windows 10 Pro. PassMark Performance Test show no issues, Reaper and Cubase are working with 256 buffer sizes without any issues.

But maybe we can boil it down: Would you be able to specify a recommended Windows setup capable of handling two 4k screens (Mixbus enlarged to those screens) and 80 mono tracks with reasonable buffer settings? Do you have specific test systems where these issues I described doesn't appear?

Because I would really love to use Mixbus as a central component in my workflow.

[johne53]

Mixbus (like many windows apps) provides our own .dll libraries rather than depend on anything on the system. This avoids the old "DLL Hell" that plagued windows applications for many years.

I've just been reading through these posts and I'm sorry to contradict you Ben, but I've a feeling you're misunderstanding the problem! gcc absolutely does suffer from DLL Hell (let me explain....)

In the bad old days (Win98 and earlier) DLL Hell was was a very common problem, where different apps would all be expecting different versions of shared DLLs. These aren't the Mixbus support DLL's, like glib and pango etc. They'll usually be the Windows system DLLs (which handle the very low-level functionality). All apps - even gcc apps - must use these ultimately, to handle stuff like memory management / file I/O etc.

To combat DLL Hell, Microsoft's own compilers introduced a concept called WinSxS (side-by-side assemblies). This allows any (Microsoft compiled) app to specify precisely which version of a DLL it wants to use. All the different DLL flavours get stored in a special folder ('C:\Windows\winsxs'). Then at runtime, Windows makes sure that each app gets the specific version it requested.

The main aim of WinSxS is to ensure that any Microsoft compiled app will run identically for different users. It's not a perfect solution because other factors come into play too (folder permissions / missing fonts / hardware anomalies etc) but for the software per se, WinSxS does a surprisingly good job. Unfortunately gcc compilers don't offer anything similar AFAIK, so a gcc app is much more likely to exhibit different behaviour for different users (i.e. what's normally referred to as "DLL Hell"). Sorry....

[x42]

PassMark Performance Test show no issues, Reaper and Cubase are working with 256 buffer sizes without any issues.

Try adding an EQ and Compressor to each tracks and run them live in Reaper or Cubase.. I expect it'll have similar realtime issues as Mixbus does, even with low overall CPU load.

But resizing the mixbus pane takes several seconds.

Resizing is a different issue, not related to cairo or windows.

[johne53]

Try adding an EQ and Compressor to each tracks and run them live in Reaper or Cubase.. I expect it'll have similar realtime issues as Mixbus does

Yes, absolutely!! In fact I once tried this with Ardour (adding an 3rd party EQ and Compressor plugin to every track). I picked the most efficient plugins I could find but it still ended up waaaay worse than Mixbus.!