It might help if you could complain about this directly to the JUCE team here: https://forum.juce.com/t/mac-m1-thread-priority-audio-workgroups/52188/12What exactly should we say? I assume it’s to complain about JUCE and not Unify
I suggest the following:
I'm a long-time user of Unify, a JUCE-based combination host/plug-in from PlugInGuru. It runs poorly on my new Mac Studio, with a lot of CPU spiking. I have already complained to the developers, who have told me this only happens on the Pro/Max versions of the M1 chip, and requested that I report this directly to the JUCE development team. I see that this phenomenon, which affects other multi-threaded JUCE apps/plug-ins, has been discussed extensively on the JUCE Forum for a year, but there is still no official solution. I urge you to address this as soon as possible.
If you do choose to post either on the GitHub Issues page, or on the JUCE Forum, please add a link here in this thread so I can be sure to follow it.
- Thanks Dr. Dunne.
It really is a pity. I have an M1Max MacBook Pro with 64GB RAM and a 4TB SSD, so these JUCE-caused Unify spikes aren’t very welcome.
It really is a pity. I have an M1Max MacBook Pro with 64GB RAM and a 4TB SSD, so these JUCE-caused Unify spikes aren’t very welcome.
I hear you. It's more than a pity; it's extremely frustrating. However, I have hope that the JUCE team will eventually deliver a permanent solution, because Unify is not the only product affected by this.
- Thanks Dr. Dunne.
It really is a pity. I have an M1Max MacBook Pro with 64GB RAM and a 4TB SSD, so these JUCE-caused Unify spikes aren’t very welcome.
I'm in the same boat as you, it is super frustrating.
I also want to say that "max thread priority" checkbox in Unify settings is not available in the plugin version, I use Unify mainly in Cubase (and it is already ticked in the standalone Unify app), and a buffer length of 256 or more is not really a good workaround, it still spikes.
I'll report it as suggested (and hopefully more will do that).
@getdunne : https://forum.juce.com/t/mac-m1-thread-priority-audio-workgroups/52188/15?u=myuusic
Hey @getdunne
is this now the solution everyone has been waiting for? Just wanted to check as I don't understand everything, because I am not a developer
https://forum.juce.com/t/fr-thread-priority-vs-efficiency-performance-cores/49025/50
edit: The more I read the comments, the more I fear it is still not a guarantee
is this now the solution everyone has been waiting for?
Well, at least it's what I've been waiting for from the JUCE team. They've been saying they have it for over a year now, but as you see, only made it public 4 days ago. Another developer actually tipped me off about this already.
It will take me some time to evaluate this for Unify. Unify is currently built on JUCE v6.1.6, with several of my own modifications and fixes, but this new code is only available in the develop branch of JUCE 7.0.7. I do have a version of Unify which will build with JUCE 7, but even if this new Audio Workgroup code worked perfectly, it wouldn't be ready to ship until I can port all my mods and fixes over to JUCE 7. Furthermore, the develop branch is basically new experimental stuff, which shouldn't be considered stable enough to ship, so I'd prefer to wait until they move it to the main branch.
Despite all those caveats, this is indeed good news, and I plan to look into this over the coming weeks.
Ah this all makes sense to me! This really doesn't sound easy, hope all goes as smooth as it can be for you. Fingers crossed!
nice to see some movement on this! let me know if you need another tester! Would be glad to help of course!
For a glimpse of what it's like one the bleeding edge of JUCE development, see https://forum.juce.com/t/auhostingservicexpc-arrow-crashing-consistently-on-release-au-builds-using-latest-develop-branch/57790
@getdunne You may want to take a look at these threads about that specific error message. Looks like it could be a Logic issue:
https://www.reddit.com/r/Logic_Studio/comments/uwmnjm/an_audio_unit_plugin_reported_a_problem_which/
https://www.reddit.com/r/LogicPro/comments/11wqxfl/i_keep_getting_an_error_that_says_an_audio_unit/
Thank you for the links, but of course I had already seen those. Search for any problem on the internet, and you'll find a torrent of near-misses dating back many years. Finding actual solutions is rare. In this case, after trying to "fix" my code in every way I could think of, I finally started from scratch and proved that my code wasn't the problem at all. To his great credit, reuk of the JUCE team responded with a solution in just one hour--on a Sunday.
Whether or not this actually solves the problem of CPU usage on M-series Macs remains to be seen. At this point, all I really know is that it doesn't crash.
well, let me make life even more confusing. Sonoma RC installed... Buffer size 32... no cracks and pops... in fact, I can even run Pianoteq 8 at 16... not kidding. USB direct from MacStudio to Wing as interface.
15 minute test. Nothing else changed on YOUR end, but clearly, Apple has done something different.
Not tried yet as a plugin in Logic, this is just standalone.
Truly bizarre.
I AM NOT RECOMMENDING UPDATING TO ANYONE. I have the means to test, and 40 years of development teams to try this kind of stuff.
Quick update: John and I are testing a rebuilt version of Unify, built using the latest JUCE 7 develop code, and I'm happy to say CPU spikes and audio glitching seem to be under control.
This isn't yet ready to send out, even as a beta, because I had to make some fundamental changes to Unify's threading code, and we're still finding things that broke as a result, but we're on our way.
@dolmensdude Very exciting news about MacOS Sonoma, though as always, I worry about what that might also break in Unify...
@dolmensdude Very exciting news about MacOS Sonoma, though as always, I worry about what that might also break in Unify...
yeah. The yearly cycle. Was floored though. I’ll give it a better workout later.
some weirdness about scanning AUs in both Logic and MainStage. Didn’t need to rescan in Unify, this is just what I noticed within the first minutes of trying stuff, as you say, to see what broke!
Gave it a full run. Standalone behavior improved. No caveats.
as a plugin, now also behaving as buffer=32 if unify window is open. Does not have to be focus window but while others had this, I didn’t but did note that if the settings window was open, cracks and pops were pronounced but would settle down if this window was open. I didn’t close it fully as was trying to find a buffer setting that would work, so found that both the buffer window and the settings window had to be closed. No idea why this dialog box would affect audio performance but it did so repeatedly.
still think Apple has done something to improve the situation and after Shane has had the chance to take the time to incorporate a major version number change to JUCE, plus see if their most reinvent changes for workgroup priorities actually work.
Appreciate all the efforts and am hopeful. Truly.
There’s still something for Apple to declare as their own audio apps give users to choice to go perf cores only, and then how many, yet all their documentation says you can’t do that, but assigning one’s self to a worker group at the proper level would insure that macOS would provide the requested computing resources on-time.
pfff, that was a lot.
this kind of code overhaul deserves a major version number update! With upgrade pricing. More than fair. Really.
Once again, thank you for reporting. With luck, we'll all see some nice improvements with MacOS Sonoma.
The business about needing the Unify window to be open is resolved by the new Audio Workgroups code I have been working on here. The problem is that with JUCE 6, attempts to set priority of audio worker threads silently fail and do nothing, so our threads get put onto E (efficiency) cores, and only get bumped up to P (performance) cores if the E cores get loaded up with other stuff--such as GUI event handling. Unfortunately, MacOS still sees them as low-priority and keeps bumping them back down to E cores, and this is what causes the audio glitching.
this kind of code overhaul deserves a major version number update! With upgrade pricing. More than fair. Really.
God bless you! I'm not sure everyone would agree, and I just don't feel right about asking people to pay more just to keep the same functionality they've had all along. Especially not Windows users (who are the majority), for whom this is all moot.