[SOLVED] VSL Synchron Player problems on M1 Ultra

I suggest directing this question directly to the knowledgeable support team at VSL. My humble M1 (non-ultra) does not exhibit any issues like the ones you describe, if that helps.

You might want to read/follow this thread: we started out by looking for differences between Logic and other DAWs, but in the end I think the OP found all DAWs were under-performing.
(Edit: also, what @Dietz said )

Dietz said:

I suggest directing this question directly to the knowledgeable support team at VSL. My humble M1 (non-ultra) does not exhibit any issues like the ones you describe, if that helps.

Click to expand...

Hi Dietz, yes I have already submitted my case to VSL support team but they didn't find a solution yet.
In the mean time I am asking the community to see if someone else with a M1 Ultra is experiencing such a problem.

I tried reverting back VSL Synchron Player to build 197 (which is no Apple Silicon compatible) and with it no audio issues occur, no crackles and no CPU spikes (sure, it is veeeery slow at loading samples btw and it doesn't work with Duality Strings).
It must be something VSL introduced with Apple Silicon compatibility that's not working properly with M1 Ultra large amount of cores

The CPU chart you show is very similar to what I see, and I am convinced my issue is disk access (which I am not sure why it’s required once all the samples are loaded). I really have no patience to `strace` a DAW, so I can’t prove it.

In any case, about the theory on the build, I am travelling for the next few days, but as I get back I will try with my 2020 iMac Intel i9 vs M1 Max using build 197.

yellow_lupine said:

I am experiencing bad VSL Synchron Player performance on my Mac Studio with M1 Ultra when playing back multiple instruments, no matter which DAW I use neither which audio/buffer settings I choose

Click to expand...

Which settings have you tried exactly? Specifically, it'd help to know concrete numbers for:

1. in Logic Pro, the I/O buffer size (see Logic Pro docs entry for "I/O Buffer Size")
2. in Synchron Player, the "Default Preload Size" (see this VSL doc, under "Engine Settings"); and
3. in Synchron Player, the "Preload Size" for each library (see the same VSL doc, under "Database Settings")

(Same question to @Olympum on the preload sizes, though you may not have them whilst you're on the road...)

aldous said:

Which settings have you tried exactly? Specifically, it'd help to know concrete numbers for:

1. in Logic Pro, the I/O buffer size (see Logic Pro docs entry for "I/O Buffer Size")
2. in Synchron Player, the "Default Preload Size" (see this VSL doc, under "Engine Settings"); and
3. in Synchron Player, the "Preload Size" for each library (see the same VSL doc, under "Database Settings")

(Same question to @Olympum on the preload sizes, though you may not have them whilst you're on the road...)

Click to expand...

Hi aldous,

I have tried all of the combinations of the available values for both DAW buffer size and Synchron Player Default/Preload Size. None solved the problem unfortunately, even setting them to maximum values the playback is impossible. The DAWs I have used are Studio One and Logic Pro.
All of my VSL libraries are stored into the Mac Studio internal super-fast NVMe SSD, which is Apple APFS formatted.
Activity Monitor shows the attached graphs when Synchron Player exhibit CPU spikes, but clearly the CPU has way more head room available.

yellow_lupine said:

I have tried all of the combinations of the available values for both DAW buffer size and Synchron Player Default/Preload Size. None solved the problem unfortunately, even setting them to maximum values the playback is impossible.

Click to expand...

Yes, I saw that in your original post, but I was asking for the actual numbers... I have different hardware, and I don't have Synchron player installed, and the maximum value isn't given in the documentation. So, I don't know what "maximum" means unless you tell me

aldous said:

Yes, I saw that in your original post, but I was asking for the actual numbers... I have different hardware, and I don't have Synchron player installed, and the maximum value isn't given in the documentation. So, I don't know what "maximum" means unless you tell me

Click to expand...

Logic Pro maximum buffer value is 1024 and Studio One is 2048 if I remember correctly. Synchron Player Preload Size (quantity of sampled loaded in RAM) maximum value should be 16384 (16GB). I will confirm those values when I am at the computer again

yellow_lupine said:

Logic Pro maximum buffer value is 1024 and Studio One is 2048 if I remember correctly. Synchron Player Preload Size (quantity of sampled loaded in RAM) maximum value should be 16384 (16GB). I will confirm those values when I am at the computer again

Click to expand...

It'd be good to confirm that 16384 really is the maximum value. If that's true, then that explains why @Olympum is seeing disk activity during playback: 16384 samples is only 0.34 seconds of audio. If any samples are longer than that - I think it's safe to assume most are - then it'll have to go to the disk for the rest of each sample (modulo caching.)

aldous said:

It'd be good to confirm that 16384 really is the maximum value. If that's true, then that explains why @Olympum is seeing disk activity during playback: 16384 samples is only 0.34 seconds of audio. If any samples are longer than that - I think it's safe to assume most are - then it'll have to go to the disk for the rest of each sample (modulo caching.)

Click to expand...

For most systems ~8000 should work just fine. We support sample streaming form SSDs since VI Pro 2, so at this point it's a mature and solid technology.
It's important that the samples are not located on any drive that is formatted in FAT file-system, as the performance of this formatting is just too bad for sample streaming. Use NTFS, HFS+ or APFS instead.

aldous said:

It'd be good to confirm that 16384 really is the maximum value. If that's true, then that explains why @Olympum is seeing disk activity during playback: 16384 samples is only 0.34 seconds of audio. If any samples are longer than that - I think it's safe to assume most are - then it'll have to go to the disk for the rest of each sample (modulo caching.)

Click to expand...

Hi aldous, I have just opened VSL Synchron Player preferences and I can confirm you the maximum preload size value is 32768 instead of 16384.

Ben said:

For most systems ~8000 should work just fine. We support sample streaming form SSDs since VI Pro 2, so at this point it's a mature and solid technology.

Click to expand...

Hi @Ben. Of course streaming should - and usually does! - work well in your player and others. But the OP and Olympum are having a performance problems which they/we are trying to diagnose, and there's some evidence that it's related to streaming. Olympum has been working on the assumption that the samples are fully loaded, but it turns out this cannot be true. I'm only pointing this out because faulty assumptions waste so much time when debugging anything.

So - a total guess, but for example - the behaviour reported by both posters could arise if the player's streaming threads were being serialised inappropriately (esp. via spin locks) on certain hardware. This can happen for all kinds of reasons, like accidentally synchronising multiple threads by requesting memory allocations from a shared heap.

I just saw this, it feels surprisingly related given that we see many more threads per core with Synchron Player v-v SINE or K7. Personally, I don’t have a spare system to try this, so I will be waiting for the 14.1 OS Sonoma release before upgrading.

Olympum said:

I just saw this, it feels surprisingly related given that we see many more threads per core with Synchron Player v-v SINE or K7. Personally, I don’t have a spare system to try this, so I will be waiting for the 14.1 OS Sonoma release before upgrading.

Has MacOS Sonoma Fixed Multicore Performance for Apple Silicon?

In the world of audio software, keeping up with hardware advancements is crucial. Back in 2021, we made strides in our mission to enhance audio processing performance, and released updates …

www.bluecataudio.com

Click to expand...

Hi Olympum,

yes I have also came across that article and in the middle of my frustration with this problem I decided to upgrade to Sonoma and... nothing changed unfortunately :(
The problem is still there, no benefits from the upgrade: I am still experiencing CPU spikes and audio crackles.

I attach here some Activity Monitor screenshots to do a comparison between VSL Synchron Player build 197 (no Apple Silicon support, wrapped by AUHostingCompatibilityService macOS utility) and build 810 (latest with Apple Silicon support).
From what I can tell it seems build 810 is not correctly handling all of the available cpu core/threads, because there are many of them completely unused (it is only using E-cores), while build 197 (or AUHostingCompatibilityService maybe, I can't tell) uses all of them.

yellow_lupine said:

I attach here some Activity Monitor screenshots to do a comparison between VSL Synchron Player build 197 (no Apple Silicon support, wrapped by AUHostingCompatibilityService macOS utility) and build 810 (latest with Apple Silicon support).

Click to expand...

Sorry to hear Sonoma didn't help - I had wondered.

CPU metering is noisy, so there's a big margin of error. The histories (red/green bar charts) don't look different enough to show a CPU allocation problem as far as I can see. Your efficiency cores are being used by something, but it looks like that's happening well before your audio task starts, towards the right of each chart. I'm not saying there's definitely not a CPU allocation problem: just that it's not obvious from those charts.

yellow_lupine said:

From what I can tell it seems build 810 is not correctly handling all of the available cpu core/threads, because there are many of them completely unused (it is only using E-cores), while build 197 (or AUHostingCompatibilityService maybe, I can't tell) uses all of them.

Click to expand...

Using more cores isn't better... (If interested, I tried to explain in another thread recently... sorry to link my own posts, but I'm going to bore the moderators to tears otherwise )

aldous said:

So - a total guess, but for example - the behaviour reported by both posters could arise if the player's streaming threads were being serialised inappropriately (esp. via spin locks) on certain hardware.

Click to expand...

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?

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.

Curious, is this an issue with all Apple silicon chips and the latest Synchron player? Or specific to the M1 Ultra?

Not on Mac but I've had issues in the past where, for unknown reasons, the time stretching was turned on and that caused the same issue. So that's something to check.

SomeGuy said:

Curious, is this an issue with all Apple silicon chips and the latest Synchron player? Or specific to the M1 Ultra?

Click to expand...

As far as I can tell this only happens on M1 Ultra CPUs.