More stable ASIO for current / future products

[John Vere]

I have to agree with @azslow3  There is definitely a huge difference in ASIO drivers between manufacturers. RME is always seems to be at the  top of the heap for a long time now.
Many manufacturers drivers are first designed for Mac users which might be a larger slice of the pie in the pro audio world.  Just open the web  page and look at the pictures at the top of the page.  Mac. 

I have 6 different brands of audio interfaces on hand and they are all definitely very different in what buffers they can work under.  I would love to be able to afford an RME but I get by OK with what I have because I also agree with @Byron Dickens and after 40 + years of audio engineer experience I don’t need turd polish to get good tracks. 
If you want power you should use Pro Tools  on Mac Book pro. 

[Misha]

While some statements are true, it seems to me that some folks just like to "insert" their views without even reading.  If everything concerning your workflow works out for you, that is great. No need to reply to thread that is of no interest to you.  I am an average user with a little better than average hardware and I do get "Stopped Audio engine" more than I would like to on interfaces that max on 2048 when mixing.

To be very clear, I don't see much of real world difference when using Cakewalk's in-house adjustments such as increasing  buffers in preference sync & caching, load balancing,  aggressive CPU etc.  

I am not looking for "advice" on optimizing my system or what DAW to use,  or purchasing a $1000 interface. But if it's possible to optimize Cakewalk to handle mixing better, when latency is not a factor  on average prosumer interfaces maxed at 2048, that would be great.

[Bruno de Souza Lino]

On 6/30/2023 at 7:03 AM, azslow3 said:

REAPER has so called "anticipative" processing

REAPER only has anticipative processing if you set it to do it in the settings. It is off by default because some plugins don't play well with it.

[Bruno de Souza Lino]

On 7/2/2023 at 4:49 AM, Misha said:

While some statements are true, it seems to me that some folks just like to "insert" their views without even reading.  If everything concerning your workflow works out for you, that is great. No need to reply to thread that is of no interest to you.

The worst offender of that are workarounds for bugs or things which are design flaws with the feature/software in question. Those are essentially admitting the problem exists without telling it so. And when these are defended instead, it's even worse.

On 7/2/2023 at 4:49 AM, Misha said:

To be very clear, I don't see much of real world difference when using Cakewalk's in-house adjustments such as increasing  buffers in preference sync & caching, load balancing,  aggressive CPU etc.  

It begs the question as which of those adjustments actually present a performance benefit in many cases, especially considering the extreme varying hardware and configurations PC users have. It's naive to assume all the optimizations one made in one system will have the same positive outcome in a completely different system, but people love to do that. Then when challenged, will proceed to back up their claim not with evidence, but with the amount of certifications they have, which mean precisely nothing in practice.

 

 

[azslow3]

15 hours ago, Bruno de Souza Lino said:

REAPER only has anticipative processing if you set it to do it in the settings. It is off by default because some plugins don't play well with it.

I don't think without this option REAPER is able significantly beat Cakewalk in number of working plug-ins. As I have mentioned, in my tests some years ago the result was opposite. Since OP has observed the effect (or at least claims he had it...), I assume anticipative processing was on.

It can be OP experience the bottleneck from completely different part of the system(s), I don't think he is using Studiocat hardware nor similarly  optimized system. But we don't know that.

Even so I had no problems with render-ahead (f.e. I don't have UAD), anticipative processing can be switched off per track. Till the effect is using some hardware, inability to work with anticipative processing will probably influence offline rendering as well (from plug-in perspective, except for GUI, that is the same). Also most DAWs support some kind of ahead rendering. I mean such plug-ins will appear "buggy" in many DAWs and particular conditions. I guess in the mean time plug-ins developers are aware.

 

[Misha]

In simple terms,  I wonder if "Extra Buffers" set in Cakewalk in  in preference sync & caching not in the ASIO driver settings can emulate behavior of (extra) buffers set in the dedicated ASIO driver settings?

For example if I am mixing at 2048 and I need 4096 for the project to be stable, adding these extra buffers in Cakewalk should act somewhat similar to increasing a buffer in the ASIO driver, but unfortunately it doesn't feel it does anything.  At least nothing close to when interface's buffers are doubled.

In short, this is what I mean by a more stable ASIO - to have extra buffer beyond what interface can offer.  For mixing.

[Starship Krupa]

A DAW that requires fiddly tuning, a specially built and optimized computer system, and a "tiptoeing around" workflow, when similar projects don't need any of that in competing DAW's is a DAW that's losing the race. And the payware race is much less forgiving than the freeware race.

Cakewalk does what I want it to, but I don't use other DAW's enough to make a comparison in regard to engine performance. None of them challenge my system in its current state.

I will say that when I first started using Cakewalk, 5 years ago, the engine did a lot of stopping. Coming from Mixcraft, which would just gradually start to have pops and crackles when I overloaded it, this was weird. I'd never used a piece of software that had an "engine" that would abruptly stop, announce that it had stopped, and then needed to be restarted like a lawnmower or outboard. And this happened a lot, so I stuck with Mixcraft and took a wait-and-see approach. If I had been evaluating SONAR Professional against other software in that price range, it would have been eliminated straightaway.

Fortunately that paid off, as Noel apparently started working on engine efficiency like it was a cure for cancer and even by the second update it had improved a great deal. I used to be able to get it to stop just by adjusting the location of the loop markers while playback was running. It could handle about 2 relocations, then it would fall on its *****.

Over the years, I've found Cakewalk's optimization options to be needlessly obtuse. The documentation usually describes what the benefits might be and just says to back off if it causes "trouble." What I would like to see, at least in the documentation, are descriptions of what the advantages and possible disadvantages of changing those settings might be. I suspect that a lot of them were created when having two cores and 8GB of RAM was a top end system. So if the disadvantage of adding extra plug-in buffers or whatever is that it eats up more memory, I don't care. My system has 16GB and rarely gets to the point of using over half of it. Likewise with cores. The documentation refers to having a multiple core system or not. Nobody who's using Cakewalk doesn't have at least 2 cores and probably 4 virtual cores to play with. My system weighs in at 10/20. Does that mean that I should be using model 3? If so, could there be a system profiler utility like many games have that surveys the users' system hardware and makes performance suggestions? Playback and recording I/O buffer size? I have no idea. The docs don't say what the drawbacks might be, so I don't know how high I can crank them. If as I said earlier it just uses more memory, I have way more of that than my projects usually need.

So, I'd like to see better default settings out of the box that take into account systems that people are likely to have in 2023. A profiler would be the next better choice, with the best being the adaptive thing that @Misha suggests.

"You need to learn how to use a DAW or go buy a different interface" helps nothing and  comes off as condescending.

I've been giving CbB a lot of slack over the past 5 years because it was freeware. But now that Cakewalk Sonar is going to be trying to compete in the payware world with such competitors as Studio One Artist at $99, REAPER at $60, Mixcraft at $79, they're going to have to up their game. People who step up and point out how they think things could be improved, especially in comparison to other DAW's, should be encouraged.

I've heard people say that it's so hard to compare performance between two DAW's, but I disagree. Start with a project on the DAW that's having dropout problems. If it has audio, drop the audio tracks into the competing DAW. If it has MIDI, transfer that. Then put all the plug-ins on. If they don't use internal plug-in managers, twiddle their settings (doesn't have to be exact) and hit play. It's not trying to create a masterpiece mix in the other DAW, just seeing how it handles a similar load.

[Ewoof]

Yeah I had this issue a year ago. The solution was unconventional. I deleted ASIO4all and used two different ASIOS: FLASIO and SSLASIO. Each has its benefits. FL ASIO allows you to use other apps while Cakewalk is open. It is also very stable and it sends a louder signal through the output. The only thing was the buffer size could go low to just 128. . If I need a smaller buffer size I use SSL ASIO. It is not as loud as FLASIO. 

To get the ASIO you just have to download the trial of FL Studio it should work.

You can only use it if you have the SSL audio interface and you can only use it if the SSL is connected. 
 

So yeah. FLASIO for general use, SSLASIO for recording and monitoring.

 

EDIT:

"FL ASIO" is another WDM-to-ASIO wrapper like ASIO4ALL. From the FL Studio documentation: "If your audio device does not natively support ASIO, the FL Studio install includes FL Studio ASIO and ASIO4ALL....

In other words, if your audio device does support ASIO, as in an ASIO driver made by the company that produces the device, don't use FL ASIO or ASIO4ALL."

And if it doesn't, WASAPI Exclusive is a better option than ASIO4ALL or "FL ASIO" or "Magix Low-Latency driver" or whatever other color of lipstick they've put on the pig.

 

So just use the SSL ASIO if you have an SSL audio interface.

Edited July 11, 2023 by Ewoof

[Starship Krupa]

5 hours ago, Ewoof said:

To get the ASIO you just have to download the trial of FL Studio it should work.

You can only use it if you have the SSL audio interface and you can only use it if the SSL is connected.

🤦‍♂️

"FL ASIO" is another WDM-to-ASIO wrapper like ASIO4ALL. From the FL Studio documentation: "If your audio device does not natively support ASIO, the FL Studio install includes FL Studio ASIO and ASIO4ALL...."

In other words, if your audio device does support ASIO, as in an ASIO driver made by the company that produces the device, don't use FL ASIO or ASIO4ALL."

And if it doesn't, WASAPI Exclusive is a better option than ASIO4ALL or "FL ASIO" or "Magix Low-Latency driver" or whatever other color of lipstick they've put on the pig.

In the case of an SSL audio interface, yes, the best driver will be the SSL ASIO driver.

And really, the only time to even use WASAPI is with a computer's built-in audio CODEC chip (usually Realtek), because nobody should ever buy an interface for use with a DAW that doesn't have its own native ASIO driver. If you want your different Windows programs to be able to use the interface at the same time, then WASAPI Shared is the right driver mode.

[Ewoof]

7 hours ago, Starship Krupa said:

🤦‍♂️

"FL ASIO" is another WDM-to-ASIO wrapper like ASIO4ALL. From the FL Studio documentation: "If your audio device does not natively support ASIO, the FL Studio install includes FL Studio ASIO and ASIO4ALL...."

In other words, if your audio device does support ASIO, as in an ASIO driver made by the company that produces the device, don't use FL ASIO or ASIO4ALL."

And if it doesn't, WASAPI Exclusive is a better option than ASIO4ALL or "FL ASIO" or "Magix Low-Latency driver" or whatever other color of lipstick they've put on the pig.

In the case of an SSL audio interface, yes, the best driver will be the SSL ASIO driver.

And really, the only time to even use WASAPI is with a computer's built-in audio CODEC chip (usually Realtek), because nobody should ever buy an interface for use with a DAW that doesn't have its own native ASIO driver. If you want your different Windows programs to be able to use the interface at the same time, then WASAPI Shared is the right driver mode.

Yeah thanks I didn't know that about FL ASIO and ASIO4ALL. My WASAPI wasn't even an option because it was not working so I had to find this workaround. I will make sure to edit my response.

[Starship Krupa]

19 minutes ago, Ewoof said:

My WASAPI wasn't even an option because it was not working so I had to find this workaround

Happily, using SSL's ASIO driver isn't the "workaround," it's best practice, so good on ya for finding that solution.

[Jim Fogle]

@Starship Krupa made a wonderful thought: 

Quote

So, I'd like to see better default settings out of the box that take into account systems that people are likely to have in 2023. A profiler would be the next better choice, with the best being the adaptive thing that @Misha suggests.