Menu
What's new
By:
Filters

[SOLVED] VSL Synchron Player problems on M1 Ultra

aldous said:
I was thinking: you can eliminate this as a cause by reducing the number of streaming threads from, say, 4 to 2: if it improves performance (rather than reducing it as expected) then that suggests those threads are getting incorrectly serialised. Either of @yellow_lupine or @Olympum fancy giving that a try?
Click to expand...
I have just tried changing streaming threads from 4 to 2, but I really can't tell if the performance increased, because audio playback is completely crackling and CPU indicators seem similar to when I set 4 streaming threads.
At this link you can find a video of my project playback with audio included.

By the way: I assume you're still looking for ideas? If it's a bug that's been reported, reproduced and understood by VSL, with a fix incoming, then there's obviously no point doing anything else here.
Click to expand...
Yes I am still looking for ideas, because VSL can't reproduce the issue since they do not have a M1 Ultra Mac at their disposal.
I have already invited them to use my Mac as a remote testing/debugging machine to help identify the problem but I haven't received any response to this yet.
@Ben could you please tell me if that is a possible solution?

At the moment I am completely unable to use all of my purchased VSL libraries :(
 
yellow_lupine said:
I have just tried changing streaming threads from 4 to 2, but I really can't tell if the performance increased, because audio playback is completely crackling and CPU indicators seem similar to when I set 4 streaming threads.
At this link you can find a video of my project playback with audio included.


Yes I am still looking for ideas, because VSL can't reproduce the issue since they do not have a M1 Ultra Mac at their disposal.
I have already invited them to use my Mac as a remote testing/debugging machine to help identify the problem but I haven't received any response to this yet.
@Ben could you please tell me if that is a possible solution?

At the moment I am completely unable to use all of my purchased VSL libraries :(
Click to expand...
I think I have all the libraries you have. If you want to send me the project, I can try to run it on my M1 Ultra.
 
I am seeing similar behavior on my M1 Max, whereas I had no issues in the past with the M1 Pro. The ultra is essentially two Max, AFAIK.

I can’t retest till I am back from traveling, but for further context:

1. I did not see any difference whether the preload was 4K or 32k and whether I force load or unload the samples.
2. In Logic, but not in Cubase, reducing the number of streaming and loading threads helps to slightly avoid the red system CPU spikes causing the drops. Similarly reducing the number of threads in Logic to 4 out of 10 in my case also helps. Increasing the buffer does not help beyond 256 bytes.
3. In Cubase the ASIO peaks almost immediately, and it’s unusable.
4. The only semi workable solution requires connecting to VEP running locally where I can run 26 tracks. Still not what I expected but somewhat workable. Now, compared to hundreds of tracks for other libraries which are SINE or Kontakt based, Synchron Player’s is a very low number.

I really want this to work. I like the predictability, the accuracy, the variety of articulations and ability to shape the sound with the Synchron libraries. But it’s frustrating to feel handicapped like this.
 
aldous said:
I was thinking: you can eliminate this as a cause by reducing the number of streaming threads from, say, 4 to 2: if it improves performance (rather than reducing it as expected) then that suggests those threads are getting incorrectly serialised. Either of @yellow_lupine or @Olympum fancy giving that a try?
Click to expand...
Both emilio_n and I have tried setting Logic processing threads from automatic to 2 and by doing this the audio plays smoothly without crackles, but obviously all of the remaining threads of M1 Ultra remain unused, so VSL Synchron Player is probably incorrectly serializing threads.
 
Last edited:
I am actually glad to see this, it confirms at least I am not crazy nor seeing a problem isolated to my setup.
 
yellow_lupine said:
At this link you can find a video of my project playback with audio included.
Click to expand...
That's useful to see/hear. It definitely looks like your efficiency cores are busy before you start playing audio, so that seems unrelated to your playback issue. Also, that isn't the kind of crackling audio I expected... does Studio One handle that differently to Logic? It sounds like it's allowing time to stretch when it can't render each time-slice in time, whereas Logic usually crackles/pops a bit and quickly gives up with a System Overload message.

yellow_lupine said:
I have already invited them to use my Mac as a remote testing/debugging machine to help identify the problem but I haven't received any response to this yet.
Click to expand...
Just FYI, there are some good reasons why they might not take up your offer: any serious debugging would require a machine with System Integrity Protection disabled, and that's not really something I'd want to do (or suggest someone else does), especially whilst connected to the internet.

yellow_lupine said:
Both emilio_n and I have tried setting Logic processing threads from automatic to 2 and by doing this the audio plays smoothly without crackles
Click to expand...
I was talking about the "streaming threads" setting in VSL's settings, but that's still interesting. The theory is a bit different, though, if playback improves with fewer processing threads but doesn't improve with fewer streaming threads. How do your CPU charts look when it's set to just two processing threads (and the default number of streaming threads)?

yellow_lupine said:
, but obviously all of the remaining threads of M1 Ultra remain unused
Click to expand...
If you're referring to CPU cores remaining unused(?) then that's not a problem; that's normal and good when rendering audio.
 
aldous said:
I was talking about the "streaming threads" setting in VSL's settings, but that's still interesting. The theory is a bit different, though, if playback improves with fewer processing threads but doesn't improve with fewer streaming threads. How do your CPU charts look when it's set to just two processing threads (and the default number of streaming threads)?
Click to expand...
Hi aldous,

here is a video of Logic playback with processing threads set to auto, while here is a video with processing threads set to 2.
 
yellow_lupine said:
here is a video of Logic playback with processing threads set to auto, while here is a video with processing threads set to 2.
Click to expand...
It's difficult to be absolutely sure just from charts, but yes, it still looks like those threads are fighting over a shared resource (like this). It's especially interesting that Logic is showing its threads maxed out, whilst the OS CPU meters are showing very little CPU utilisation: Logic's bar charts measure a combination of CPU+memory+disk throughput for each thread, whereas the MacOS CPU meters are just showing CPU. So, further evidence that the system's spending most of its time waiting on data.

I'm running low on ideas that aren't either very technical or slightly dangerous (or both)... but will come back if I have any more ideas.
 
Back at the office, I can confirm that the spikes / cracks / pops don't occur with build 197 (but Duality does not work), so something is off with the Apple silicon code.

In Logic, I have managed to get a stable setup by setting to 2 or 4 threads instead of automatic (10), with a 256 bytes buffer.

In Cubase, I also managed to get a stable setup by either setting the buffer size to 2048 bytes and disabling ASIO, or by using VEP locally with 4 buffers.

Something is off and I hope VSL can address it soon.
 
Ben said:
@Olympum We are testing a beta build of VEP7 right now that improves thread-grouping for Apple Silicon, especially on Max and Ultra CPUs.
If you are interested in checking it out I'm happy to send you a download link via PM.
Click to expand...
Hi Ben I am really interested into that build, could you please PM it?
I was expecting also a Synchron Player beta build.
 
yellow_lupine said:
Hi Ben I am really interested into that build, could you please PM it?
I was expecting also a Synchron Player beta build.
Click to expand...
Synchron Player is a single threading plugin, so the host application / OS has to decide how threads are spread out on CPU cores.
That's why we can only improve threading in VEP, not in the Synchron Player itself.

I'll PM you the beta link.
 
Ben said:
Synchron Player is a single threading plugin, so the host application / OS has to decide how threads are spread out on CPU cores.
That's why we can only improve threading in VEP, not in the Synchron Player itself.

I'll PM you the beta link.
Click to expand...
Thanks for the link.

If I have quite understood your Synchron Player developers can't do much to make it work successfully alone in M1 Ultra, because it will only work correctly if embedded in VEP or by manually imposing the DAW to restrict the number of used threads. Am I correct?
 
yellow_lupine said:
If I have quite understood your Synchron Player developers can't do much to make it work successfully alone in M1 Ultra, because it will only work correctly if embedded in VEP or by manually imposing the DAW to restrict the number of used threads. Am I correct?
Click to expand...
If I'm not mistaken the host (your DAW or VEP) is responsible for how it manages threads and tells the OS what to do with it.
We can change this behavior in VEP with an update of the hosting code, but we can't change DAW behavior.

As far as I know the issue is that e-cores are being used for path-critical processing instead of p-cores, causing this issue. This is also the reason why you can see similar behavior on Windows since Intel's 12th gen CPUs, but not with AMD CPUs (they don't come with e-cores).
The Windows VEP beta build also addresses the Intel 12th+ gen performance issues.
 
Ben said:
If I'm not mistaken the host (your DAW or VEP) is responsible for how it manages threads and tells the OS what to do with it.
We can change this behavior in VEP with an update of the hosting code, but we can't change DAW behavior.

As far as I know the issue is that e-cores are being used for path-critical processing instead of p-cores, causing this issue. This is also the reason why you can see similar behavior on Windows since Intel's 12th gen CPUs, but not with AMD CPUs (they don't come with e-cores).
The Windows VEP beta build also addresses the Intel 12th+ gen performance issues.
Click to expand...
Please, forgive my ignorance on this but shouldn't other virtual instruments have this same problem then?
I tried using a bunch of other vendors instruments plugins with multiple mics and they don't seem to clog the CPU like that. Is it because Synchron Player is single threaded and others are probably multithreaded?
 
yellow_lupine said:
Please, forgive my ignorance on this but shouldn't other virtual instruments have this same problem then?
I tried using a bunch of other vendors instruments plugins with multiple mics and they don't seem to clog the CPU like that. Is it because Synchron Player is single threaded and others are probably multithreaded?
Click to expand...
Sorry, I don't have enough knowledge about other plugins and MacOS, since I'm personally mainly a Windows user and dev, so I can't comment on that.
With Intel CPUs it's easy to do a quick check since you can simply disable e-cores in the bios; this is to my knowledge not possible with a Mac.

My best guess: The OS decides that the Synchron Player is a low-demanding thread that would not need the power of a p-core and moves it to e-cores, but these are not able to process data in time as soon as you enter real-time mode (playback, recording).
But that's just a wild guess. I would have to speak with my dev colleagues to confirm this or get a better explaination.
 
Ben said:
We are testing a beta build of VEP7 right now that improves thread-grouping for Apple Silicon, especially on Max and Ultra CPUs.
If you are interested in checking it out I'm happy to send you a download link via PM.
Click to expand...
Hi Ben, I've been tracking this thread, as I also have a Mac Studio M1 Ultra and have been running into these problems. Would you PM me a download link too? Thanks!
 
Ben's note on e-core vs p-core on Apple Silicon I think is spot on. I have found that Cubase produces the cracks and pops at much lower track count when hosting the Synchron Player vs when it's VEP7 the one hosting it. Looking at Activity Monitor I can see that whereas Cubase (both C12 and C13) is maxing the e-cores and not really leveraging the p-cores, VEP is leveraging the p-cores. As for Logic, when changing from Automatic to 2 or 4 performance threads, it's basically avoiding the e-cores.

So I went on to see what else was running in the system, and I killed absolutely every process, regardless how minor it could be. Most daemons run in the e-cores, and not the p-cores, so the system is naturally "busy" and any minor change will impact the real-time audio pipeline. Well I can now report that with Cubase+VEP7 I can finally host the whole orchestra without cracks and pops, just like I could in Logic. For reference, my settings are 512 bytes buffer in Cubase, 4 buffers in VEP7, and 4 threads per instance in VEP7. I have ASIO to High, but it's irrelevant since I have it disabled for the VEP plugin. I think this is possible since VEP pushes load to the p-cores, because even after the cleanup, Cubase is unable to run the full orchestra as it keeps pushing the e-cores.
 
You must log in or register to reply here.
Top Bottom