Audio engine cutting out

Strange indeed. What are your audio interface/interface settings (driver selected)/OS?

Did you try Unify2 in a DAW/Other plugin host and experience any issues with audio there?

@ptumelty

When you change patch, are you selecting a patch from a Unify-only library?  That is, a patch using only Unify?  Or is the patch using a 3rd party VST (Omnisphere, Serum, Native Instruments, etc.)?  Super odd issue.

It's a universal audio x8 apollo gen 2 interface (ASIO, native thunderbolt driver), only 4 weeks old.

I have no problem with Unify 2 in a VST host, be it a DAW, Cantabile, Gig Performer etc. It's only happening in the standalone version.

It happens with any patch. If you hold a key down on startup, you can her the init tone, if you then change patch, you will hear the first few ms of the new patch, then it just cuts out until you reset the audio. This is with Native Unify libraries, and patches that use third party VST's.

I did wonder if this was a sample rate issue where the standalone version wasn't matching windows, but putting both of these to 48000Hz doesn't change anything.

I have way too many other VST's that all come with standalone versions, and these all work absolutely fine. I've never seen anything like this.

Have you selected the ASIO driver in the audio settings of Unify2? It won't work well with Windows Audio.

Also, don't try using Unify stand-alone while some other program (e.g. your DAW) is using the interface.

Thanks, Yes, well aware of this.

It’s definitely not a problem with another app as it works on first load with the init tone.

Also, I’m using the correct ASIO driver. I wouldn’t spend nearly £3000 on an interface and then use windows audio 😉

I should add for context that i have a degree in computer science, have been developing software for 25 years professionally and doing music on PC for years. Basically, i know my way around setting things up 🙂 This is something I’ve never encountered before.

I really appreciate the suggestions but it’s not something I’ve done wrong, it seems to be a bug with Unify to me

I think the problem is we didn't charge you 1000$ for the software 😉 

Sorry please confirm again, your interface settings - in the standalone mode:

Samplerate / block size.

Also CPU type/generation/system RAM?

A screenshot of the audio settings panel may help.

Also one more thing - I know you know your way around systems obviously, but one thing that has caught me out on the past has been when the selected hardware interface was the ASIO driver / audio interface as you would expect, but then if a audio input from a different device was selected in the input list, it could create all sorts of issues.

With Universal Audio Apollo Twin hardware I used in the past, I also had some issues with getting stable audio when the BIOS was set to use Intel speedstep (don't know if that's even an option on recent PCs/CPUs) - and may not apply for your system obviously.

I'm testing on Presonus and RME interfaces currently - and not seen any issues with Standalone audio in Win 11 / Core i9 10th gen or an even older 9th gen i7 laptop.

If this persists I'll have to put together a logging build we can run to try see what's happening if you can wait for that.

One more question.. do you have Unify1 - if so is this only seen in Unify2 on your system or also Unify 1?  (They should be pretty similar though in terms of the rendering code, they are very similar engines)

Thanks again for your help, just wanted to let you know my background and that I'm pretty good at figuring out stuff like this. I've never had a problem with any other VST standalone or DAW/other VST host. I hope I didn't come across as arrogant and ungrateful as that was certainly not the intent.

To answer both questions from above. It is a new interface, I've only had it four weeks or so (but machine itself is about 18 months old, i9-14900k, 128GB DDR5 RAM and about 10GB of NVME SSD storage

It crossed my mind that I've never actually ran Unify 1 standalone on it since switching interface. I ran Unify 1 and I'm seeing exactly the same problem, but both work perfectly inside a VST host like Cantabile which I use for playing about with.

These are my settings (see attached) in Unify 2 (left) and Unify (right). Looks like I can only attach one file, so I'll attach the settings for reference from Pianoteq 9 and the Arturia CS-80V4 standalone apps which are identical and working perfectly

I did notice (as mentioned above) that sample rates were different in Unify vs Windows, but syncing these to the windows sample rate 48000Hz didn't help.

I've disabled all of the step-speed stuff in the bios so everything is running full power. Everything is rock solid with the new card in all the other apps I have.

I'd previously had a year of hell with the TB2 Steinberg AXR4-T (which I could only get working by downgrading the TB firmware on my BIOS due to a change in the TB4 spec to remove backwards compatibility with TB2 via an adapter). The AXR4T would often go missing in windows and need the BIOS reflashing or a BIOS reset to get it back. I would have to turn it on before bootup and then pray it was detected on startup (it often wasn't). Sometimes a reboot would fix it, othertimes not, it was totally random. It also cause other random issues which I won't go into for the sake of my sanity 🙂

I eventually bit the bullet and dropped a fortune on the UA card. This is TB3, everything has been working beautifully. I can switch the device on and off after booting and it just connects instantly. I don't have to remember to turn it on first and then cross my fingers!

Any ideas would be much appreciated. As I said, if i hold a key down and change preset, I briefly hear about 0.1 seconds of the new sound and then nothing so it does seem to briefly work

One thing to add... There are a LOT of inputs and outputs on this thing. 34 inputs and 32 outputs as it's also connected to a Focusrite Octopre 🙂

Pianoteq settings all work fine

CS-80V4 settings all work fine

@ptumelty After looking at your audio settings in Unify V1 and V2, I am curious what would happen if you try an audio buffer size of 512 or 256 samples? Unify operates best at these sizes and anything lower or higher than that may cause issues on some machines. Not making promises that it will fix it, but it has fixed audio issues for others in the past, so it may be worth a shot 🙂

Well would you believe it, thats fixed it!

Very strange. I can run as low as 32 buffer in all the other standalone VST apps (and I have loads!) and it works well with no dropout. Interestingly perhaps, Unify 2 works fine inside Cantabile with 32 sample rate.....

Thanks for your help, I would never have thought that a low buffer on a specific application could cause no sound output at all. I'm used to just hearing artifacts and dropouts if buffer is too small (although not heard this once since switching to the UA card!)

Seems you can teach an old dog new tricks 😉

Perhaps there is still a bit of work to do debugging U1+2 with 128 samples or below, but happy it's working for now.

I've updated the main topic with the fix 🙂

@ptumelty

Unify's multi-threading works on a per-buffer basis, so it becomes inefficient at very small buffer sizes.

Cantabile might use a larger buffer size internally; I don't know much about it. It's also possible that the audio callback implementation in Unify just isn't as streamlined as Cantabile's.

These things can be hugely mysterious and irritating. My dev PC is an AMD Ryzen 7950X with 16 full-performance cores, and I still haven't figured out how to get rid of audio glitching, regardless of buffer size, whereas Unify/Unify2 runs smooth as silk on my Macs, and even on an old 2-core Win7 PC.

Glad to see this has been figured out. For sure dropping to really small block sizes could become less efficient for multi-threading, it's something I've talked about in my notes on multi-threaded audio here: https://www.wavesequencer.com/news/cpu-performance-discussion

128 samples is very good latency wise and still should be OK for Unify2 (with 64 samples I get crackling on complex patches like 'Arrival - IV' at 48KHz on my 10th gen i9 + Presonus interface), I stick to 256 usually - 512/48KHz (10ms latency) is a bit high for live playing. 

It would be good to support any block size though, and this is probably related to the issues we've been seeing with FL studio variable block size requests (and I have a solution I used to fix that problem in Hyperion with FIFO usage, but it can add latency).

It's unfortunately still the case that Mac OS seems to do a better job with smaller buffers in general.

Just to note, I can get no crackling/break up of Audio on my Presonus studio 24c (150$) interface with 128 samples/48KHz and Win11 on a 10th Gen i9 (it's a 12 core processor/24 threads - so still pretty decent) - it's doing just fine with some pretty complex Unify patches in standalone mode (e.g Lost in the Abyss U2 with the metronome running, playing 6-8 notes held down - getting around 30% audio load).

The i9 14900K should in theory blow my system out the water.. a i9-10920X/32Gig ddr4 - maybe because your interface is dealing with many active channels - but if you just select a stereo output in standalone.. it shouldn't be processing more than that... even then doesn't make a lot of sense.

The newer Intel chips have that same big/little style architecture as Apple's chips, but Windows OS doesn't have an audio API designed to optimize core allocation based on audio load/thread sleep/expected process time - with Apple silicon the audio workgroups API gives the OS a better clue as to how to schedule audio threads and whether to shift them to p-cores or e-cores.

 (I need to get myself a test machine actually - currently have nothing with these newer Intel chip types)

Yes, there's only one output selected when I run as standalone.

To be honest, on my old interface, I'd always have the buffer set to 256 as the latency was low enough that it was perfectly playable. No point stressing the CPU for the sake of it and better to give it a bit of breathing room.

It's only since the new interface that I've been pushing it to see how low I could go. Nothing has dropped out on me yet (other than the issue yesterday), and to be honest, I'd forgotten it was even so low!

Out of interest, I did a quick test with the Arrival IV patch, through U2 in Cantabile, 32 samples.

I couldn't force any artifacts are dropouts no matter what I did and that was basically holding at least 17-20 keys down, 5 in the left hand and then using my forearm to press about two octaves worth of white keys 🙂

I had task manager open at this time and none of the 32 cores were above 30%. The overall CPU usage shows as 10%

So it does seem like U/U2 is capable of running as low as 32 samples with complex patches, but there seems to be some difference running standalone to hosted. I guess they have their own multi-threaded code as well which will come into play. I don't envy you working on all this.  Threading is one of my least favourite bits of programming!

@ptumelty Your interface may be set to 32 samples, but internally Cantabile could possibly be buffering things up to make larger block requests to the plugins it is hosting. I may add a hidden logging page in the UI in future to capture things like block size/sample rate config changes as they happen - it would be helpful to figure out things like this.

Just updated to the latest version of U2 and was hoping this problem might have been fixed, but it's still an issue for me. I have to reset the audio interface using the "Reset Device" button in the audio/midi options after each patch change. Once I do this, it's fine until I change patch again.

This only happens in standalone mode

Did you manage to look into this any more? I can't be the only one it happens to?

Sorry for slow response - I've been away at Synthfest in France and just busy with many other things.

I can only say that dropping to really small block sizes will stress the audio engine of Unify2 - due to the multi-threaded nature of the processing you start to get less benefits of it when the processing blocks get really small - how bad this appears depends a lot on your CPU type and audio interface driver/OS efficiency.
How a DAW manages its processing  of Unify2 could have a lot of variables.. the sound card block size might be small, but it may actually be using a FIFO scheme internally to the DAW which results in a larger block size for track plugins - or some DAWs will use a thread per track.

I can run the standalone build down to 48 samples block size at 48KHz without issues (sounds are still playing when patch changing) with a RME Babyface Pro interface (plugged into a USB hub at the moment - not ideal), but on my relatively older 10th gen core i9 system it's noticeable that the audio load goes up significantly vs using a more commonly used block size like 256 samples.

One thing to remember is that CPU load in the task manager is not a representation of audio load - that is a factor of how much spare time we have in each audio callback to finish processing all the parallel threads we have going on - when there are lots of threads and small block sizes the thread wake/sleep and synchronization may have more impact as a proportion of the block processing time.

For standalone mode I recommend 128 to 256 samples block size - and would suggest that is a good block size within DAWs too (for live playing) - especially for Unify2 (or even Hyperion which also uses lots of parallel threads).

I may have to make some changes to the audio processing core of Unify2 to be able to better handle DAWs like FL studio - that might result in limiting how small the block size can get internally within Unify2 (with some FIFO/latency).. which would make it perform better when a DAW requests really tiny and varying size block requests, or when hardware has a very small block size. This is a potentially dangerous change, so not going to rush into that - it may be months before I look into it.