ARM updates galore beta round 01 revision 11152

[Sound Author]

Bazille's knobs and cable animations seem a bit sluggish on the M1. Not sure if it's my system or if Bazille's GUI could use some optimizations. I'm using the new Mini with 8gb of RAM but surely Bazille's GUI elements aren't THAT reliant on system memory. Dropping quite a few "frames" (not sure if that's the right nomenclature) with knob turns and dragging cables.

[Sound Author]

Ah, just ignore that last post. For some reason I got it in my head that M1 updates have already rolled out. No idea what made me think that. Carry on.

[Sound Author]

Okay, so I'm on the M1 Mac Mini, running these ARM betas on the Bitwig 4.0 beta, which has native Apple Silicon support. The performance of Diva is just awful. It was far more efficient running under Rosetta 2. Lots of spikes and dropouts. I guess maybe that has something to do with the Bitwig beta.

[Urs]

Try switching multicore off, and automatic brightness adjustment. That hasn't changed since the first few posts of this thread.

[Sound Author]

Try switching multicore off, and automatic brightness adjustment. That hasn't changed since the first few posts of this thread.

Multicore is switched off, and the automatic brightness is just a Macbook Pro/Air feature. My M1 Mac Mini has no ambient sensor. I restarted my Mini after installing all the betas and the spikes aren't as severe, but the behavior is still VERY spiky and the overall utilization is at about 30% with the default patch using 6 voices with "Great" accuracy. Not terrible performance but not very good either. It's just really, REALLY spiky. The performance was much better with the Intel version running on Rosetta 2.

[Urs]

Maybe what you're seeing is that the CPU is "too much for the economy cores but too little for the performance ones". We've seen many situations where the OS seems to wake up the faster cores of the M1 only to fall back to the slower cores shortly thereafter. Thus, CPU seems to go up even though the software uses fewer CPU cycles.

When running Rosetta, things use overall more CPU and thus things are likely to run on the performance cores. It looks like less CPU, but it's not.

[Sound Author]

Maybe what you're seeing is that the CPU is "too much for the economy cores but too little for the performance ones". We've seen many situations where the OS seems to wake up the faster cores of the M1 only to fall back to the slower cores shortly thereafter. Thus, CPU seems to go up even though the software uses fewer CPU cycles.

When running Rosetta, things use overall more CPU and thus things are likely to run on the performance cores. It looks like less CPU, but it's not.

Oh, it doesn't just seem like it's using more CPU. These massive spikes cause several audible dropouts, especially when using CPU intensive patches. Something is very wrong.

[Urs]

Something is very wrong.

In that case it would be good to know what it actually is. I wonder if access to a project file and the presets in question would help us pinpoint the issue.

[Kypresso]

Try switching multicore off, and automatic brightness adjustment. That hasn't changed since the first few posts of this thread.

Multicore is switched off, and the automatic brightness is just a Macbook Pro/Air feature. My M1 Mac Mini has no ambient sensor. I restarted my Mini after installing all the betas and the spikes aren't as severe, but the behavior is still VERY spiky and the overall utilization is at about 30% with the default patch using 6 voices with "Great" accuracy. Not terrible performance but not very good either. It's just really, REALLY spiky. The performance was much better with the Intel version running on Rosetta 2.

On my mac mini m1 ,8meg ram, with bitwig 4 beta 4 using the default init patch using 6 voices and great accuracy i get about 12% total user utilization if i hold down 12 notes. I get a slight crackle as the utilization goes from 11% to 12% and also when it goes from 12% to 11% but it sounds fine apart from that.
I also tried with divine setting and 8 voices and its about the same,this is with Bitwig taking about 4% total utilization so diva seems to add about 8%
Looking at the cpu meter, the 4 fast cores are used all the time as is 1 bar on the first slow core but there doesn't seem to be any swapping of cores.

Warning, this is my first mac so i may not be comparing like for like with these figures. I'm using the user figure from the panel at the bottom of the activity monitor utility.

[tasmaniandevil]

Something is very wrong.

In that case it would be good to know what it actually is. I wonder if access to a project file and the presets in question would help us pinpoint the issue.

Good idea.
And more specific information might also be helpful.
Like sample rate, audio buffer size, audio interface, which of the sandboxing settings of Bitwig you are using, what other apps are running next to Bitwig (e.g. web browser, ...).
We can take a look at this tomorrow.

[Sound Author]

M1 Mac Mini w 8gb RAM
Bitwig 4.0, beta 4
Driver model: Core Audio
Output Device: External Headphones
Sample rate: Automatic
Block Size: 256 samples
I don't know which of the sandboxing settings I was using before I switched it to "Together".
No other applications are running next to Bitwig.
One instance of Diva, using the default patch with 6 voices and "Great" accuracy with "Multicore" switched off utilizes about 30% CPU with massive spikes and frequent dropouts.

[tasmaniandevil]

I had a look at the Bitwig beta on the M1 Macbook Pro.
Using Big Sur 11.4, Bitwig beta 4 and Diva rev. 11152.
I assume you used the VST3 version of Diva (as Bitwig hides the VST2 by default), so I used this for testing.
Regarding sample rate "automatic", you can see the used sample rate in Bitwig's performance monitor, over here it was using 44.1kHz.
The default preset loaded at startup is a legato preset, it isn't really useful to test performance, as it only plays one voice at a time.
Thus I used the first preset in the factory library, Deep Space Diva, and played a six voice chord.
I could play 24 instances of Diva (144 voices in total) without a single CPU overload.
The performance isn't as mindblowing as in Reaper yet.
I guess Bitwig is still working on improving the distribution of CPU load over all available cores.
But so far there are no problems like the one you described.
I'd suggest to reboot the M1, and check if it is up to date (newest Big Sur version + newest Bitwig beta).
Other than that, not sure how to diagnose the issue from distance, it currently sounds as if it might be a problem with the hardware of your Mac, but that's only speculation.

[Ploki]

Okay, so I'm on the M1 Mac Mini, running these ARM betas on the Bitwig 4.0 beta, which has native Apple Silicon support. The performance of Diva is just awful. It was far more efficient running under Rosetta 2. Lots of spikes and dropouts. I guess maybe that has something to do with the Bitwig beta.

odd, in logic my diva numbers going M1 are insanely better vs rosetta2 or intel, and i don't remember having any dropouts or such while working in the past few weeks.
and i mostly keep buffer at 64

[seagate2019]

Ditto

[Lady Gaia]

The host application should probably be responsible for setting the "Quality of Service" context for the plug-in, so this sounds like it's potentially a Bitwig beta issue that should be reported. That said, it's something U-he could look into working around within the plug-ins which should have a User Interactive quality of service assigned for any work on the audio critical path. Some basics on the concept and relevant API is covered here (since I evidently still don't have enough posts for a link!?):

https://developer.apple.com/documentati ... le-silicon