AudioModeling SWAM Cello Performance Issues

[Eoin-ONeill-Yokai]

Problem description When running AudioModeling's SWAM Cello physical modeling vst through yabridge / bitwig, there were significant performance issues that caused crackling audio (often times without triggering actual xruns on the system (according to qjackctl) ) and CPU usage seemingly shot up higher than it does on other operating systems. Interestingly, SWAM Cello seems to perform pretty well when running VSTHost.exe in the same wineprefix as the swam cello plugin, though the GUI doesn't render properly. This was tested using both wine-staging (available on Majaro's pacman) and also using wine-staging-tkg w/ FSYNC patches. Changing the buffer size had seemingly little effect. Running the plugin on a higher-powered AMD machine had seemingly no change as well.

What did you expect to happen? I expect CPU usage to be high (as it's a physically modeled instrument) but I also expect vsthost.exe's instance and yabridge's instance to perform similarly to one another on equivocal (or as close as possible) buffer sizes. Currently, this does not seem to be the case. ...

System information

• Operating system: [Manjaro 20.2 Nibia]
• Wine version: [wine-5.22.r10.g2a073f33 (Staging) aka wine-staging-tkg]
• Installation method: [copies], [yabridgectl]
• yabridge version: [yabridge 1.6.1-1]
• yabridgectl version: [yabridgectl 1.6.1]

Debug log yabridge-swam-cello-fsync-abridged.log

The original log file was huge due to a repeating call to audioMasterGetTime(index = 0, value = 65024, option = 0, data = <nullptr>) which I tried to abridge in this log file to reduce the overall file size.

[robbert-vdh]

Could you first try updating yabridge to yabridge 2.1.0? There have been some major rewrites during yabridge 2.x that greatly improve performance, responsiveness and compatibility. Don't forget to rerun yabridgectl sync after updating. There's now also a separate yabridgectl (as opposed to the older yabridgectl-git) AUR package that stays in sync with the normal yabridge package to avoid potential weirdness in the future.

[CarlColglazier]

I have this plugin as well and have the same issue running yabridge 2.1.0. Makes the audio CPU use go to pretty much 100% instantly, but I can get sound out fine if I bounce/render. Happy to help test possible fixes. Arch Linux 5.9.10 + wine-5.22.

Interestingly, all the SWAM plugins seem fine except for the strings.

[Eoin-ONeill-Yokai]

Interestingly, all the SWAM plugins seem fine except for the strings.

@CarlColglazier Oh! That's good news. I assumed that they would all be the same so I didn't bother testing any of the others besides Cello. I just tested Saxophones and I have very good performance and it works flawlessly. :)

So I can confirm that the problem seems to be unique to the strings package (particularly Cello, which I've tested.)

@robbert-vdh I updated to 2.1.0 and experienced the same performance issues as before with SWAM Cellos.

[robbert-vdh]

I just downloaded the plugin myself and it does indeed seem to use a ridiculous amount of CPU. As expected all of that time is spent in the the plugin's processReplacing() function (i.e. what the host calls to ask the plugin to process audio). Usually a plugin would want to know what the current playback position is, for instance to sync up LFOs. To do this they'll do a callback to the host and ask it for the current tempo and time information by calling audioMasterGetTime() during that processReplacing() function. This plugin, however, doesn't call it just once. It calls it 512 times! So that's why the plugin is so laggy. During a single audio processing cycle, this plugin is talking back and forth with the host 512 times. This is definitely a bug in the SWAM Cello and should be reported to them. Normally this wouldn't tank performance that badly, but in yabridge's case these 512 function calls means that Linux has to switch between processes 1024 times (and double that if you're using Bitwig's sandboxing) in a single audio call. And all of that happens sample_rate / buffer_size times per second. I'd rather not add hacks to yabridge to work around bugs in specific plugins or hosts, but I'll add an option tomorrow to cache audioMasterGetTime() during a single processing cycle. That should bring the usage down to what you'd expect.

Again, this issue should definitely be reported to SWAM! They may not realize that their plugin is doing 512 callbacks per audio processing cycle.

EDIT: Those 512 times and the multiples thereof I mentioned is of course linked to your buffer/period size. So it's calling that function for every sample it processes rather than only once per processing cycle.

[CarlColglazier]

Thanks, @robbert-vdh! I submitted a ticket on their support page and linked to your explanation. I'll let you know when I hear back.

[leleswam]

Hi everyone,

it's Emanuele Parravicini, CTO at Audio Modeling. Thanks for reporting on this. Our developers have been already informed and we should be able to start working on the fix tomorrow.

Best Regards, Emanuele

[robbert-vdh]

@leleswam Thanks a lot for the quick response and for looking into this!

---

As a temporary workaround I've added a compatibility option that adds caching to this function call in 23d5567e72a2984a54ed59229336fdaef874fbb2. That should bring the performance back to the expected levels. If you're on Arch or Manjaro, then you can temporarily switch to or update the yabridge-git AUR package to get this functionality. For other distros you can download the latest build from the automated builds page. Don't forget to rerun yabridgectl sync after updating or replacing your yabridge files.

To enable this option for SWAM Cello, create or edit a yabridge.toml file in the directory of the plugin's .dll and .so file, and add the following to the top of that file:

["SWAM Cello 64bit.so"]
cache_time_info = true

[CarlColglazier]

Tested on my system (using SWAM viola) and this workaround does indeed work. Fantastic. Should also work on any other plugin with the same issue. :)

[Eoin-ONeill-Yokai]

@robbert-vdh Thanks a lot! I just tried out the patch and everything seems to work flawlessly with the caching!

[robbert-vdh]

The workaround for this is now in the just released yabridge 2.2.0! I'll keep this in until it's no longer needed anymore.