niles wroteCubase's ASIO Guard does not work for everyone either. It's a band-aid for insufficient processing power to stay compliant to the user who asks too much from his system.

In a general sense but the OP says Cubase's version and Logic's version are performing significantly better. Should we not strive for better?

This is interesting to me as I get MUCH better performance from S1 then I do from PT here. I'm able to run S1 at the 32 sample buffer with really minimal issues compared to PT where I would say the comparable buffer setting would be 128.

One thing I notice, also on Mac here (hackintoshes) is that VSTs seem to work much better than AU. Haven't done any formal testing though. I will when I get a chance.

Possibly it helps having the 18c processors. The last time I did formal tests with logic it was limited to one core for record armed tracks and that was a showstopper for my workflow (which has been a while ago now)- I prefer to work and monitor through full templates. I'll have to do a little more testing when I have a chance.

ryanconway1 wroteThis is interesting to me as I get MUCH better performance from S1 then I do from PT here. I'm able to run S1 at the 32 sample buffer with really minimal issues compared to PT where I would say the comparable buffer setting would be 128.

One thing I notice, also on Mac here (hackintoshes) is that VSTs seem to work much better than AU. Haven't done any formal testing though. I will when I get a chance.

Possibly it helps having the 18c processors. The last time I did formal tests with logic it was limited to one core for record armed tracks and that was a showstopper for my workflow (which has been a while ago now)- I prefer to work and monitor through full templates. I'll have to do a little more testing when I have a chance.

Which dropout protection setting are you using?

robertgray3 wroteWhich dropout protection setting are you using?

It doesn't seem to matter all that much, but I think I left it on medium.

However, yesterday I opened up the same template that was working so well, and was getting clicks and pops. This is confusing/concerning. Possibly it's due to the fact that I'm still unfamiliar with the program, but the only thing I can think that was different is I was learning songs from youtube...

I'll mess with it some more, had some work to do so I didn't have a whole lot of time there.

Does anyone else see differences between AU and VST?

TNM wrote

robertgray3 wroteCurious to know what? Sorry I didn't really catch the point you were making.

If it was about spending hours to try and volunteer to improve software, yeah, I don't like it either. like improving the software I use but there are limits, as you mentioned. That's why I'm not really digging into this much anymore. Alan (mostly) and I tested it for a few hours and then gave up when nobody really showed interest. Can't blame them, considering the reward for this multiple days of testing is gonna be somebody maybe looking into it sometime within 1-4 years.

In the meantime, I just know it doesn't work great and try to work around it as best I can

Well I've done all the work this time. All the time consuming stuff is done.

If no one speaks up about it it will never get fixed. That's my philosophy.

I already regret buying S1 4.5.5, and because my demo is still activated and the purchased one has not been, I am actually going to ask for a refund.

See, I *can't* just work around it. My projects are big and use tons of VI's.. Right now in this state, the DAW is of no use to me on OS X. There is just no way I can do the sort of projects I am used to and have them play back.. I'd have to track transform everything and set the buffer higher for incoming recordings, the latter which I am not willing to do..

Presonus S1 is an outstanding DAW. Presonus are a hardware company too so controller support is incredible, affordable and the S1 workflow puts most other DAWs to shame. I own a StudioLive 32 Series III had a Quantum it's my main DAW and plan to stay with it for a long while to come.

One of it's feature that causes a lot of confusion though is Dropout protection. Dropout protection does NOT work on either Mac or PC and never has since it's introduction in S1 3.5.

Robert did some tests and his Mac appeared to run well compared to my Windows i7 8700K setup so I'm surprised you're having more problems on Mac Support should be able to help tweak your setup to see if there's something S1 doesn't like with it.. It may be because you have Dropout protection ON. Last time I tested this it pushed all processing on the low latency path to a single core which is I think from a quick look through your post part of what you are experiencing. Have you checked the distribution of load across your cores with dropout protection ON and OFF to see the difference in core usage?

Support are good at trying to get things working as best they can but have consistently refused to acknowledge the dropout protection issue, I've contacted them many times over the years and have sent them extensive tests proving the feature doesn't work on Windows and Robert has confirmed there are issues on Mac too.

Please do not ignore the following advice which I've posted several times on the forums:

BEST LOW LATENCY PERFORMANCE IS NORMALLY ACHIEVED WITH DROPOUT PROTECTION TURNED OFF NEVER TURN IT ON BY DEFAULT ONLY TURN IT ON AFTER YOU EXPERIENCE DROPOUTS

From my testing as of a few point releases ago S1 can't use all CPU cores and with Dropout protection ON it use only ONE core for the low latency path (i.e. anything monitor enabled and any bus, FX sends and anythign on 2Bus), so the best option is to always leave it OFF and freeze tracks as often as possible.

If there's not enough pain in your life already you've bought too deeply into the marketing hype and are desperate to use this broken feature you could try some of the following (in random order!):

1. If you have a lot of track, bus and send FX in a project hit the "disable all" power icon BEFORE record/monitor enabling any tracks this will reduce the CPU load while recording. Gain staging will be a complete mess but at least your computer won't implode. Once recording is complete take all tracks out of record/monitoring state THEN click the icon again to enable FX

2. Buy a more powerful PC - these days that often means more cores rather than better ones and to be honest S1 will choke quite quickly as last time I checked it only used a single core for record/monitor tracks for all insert FX and instruments in the low latency path so you'd still be better turning dropout protection OFF to get the best results. S1 with Dropout protection ON is definitely one of those scenarios that needs super fast O/C cores rather than more cores.

3. Offload VIs to a slave via VE Pro - if you don't mind having two PCs, the little extra buffer for the network hop and the workflow restrictions it makes a dramatic difference and works superbly with Dropout protection in S1. VE Pro seems to balance load across cores almost as well as Reaper so offers excellent utilisation on the slave PC. You can use it stand alone locally too to help balance load across cores. Also even if you're Mac based the slave could be a cheaper windows PC! There's a free VE Pro demo try this out see if you can live with it. If Presonus created their own version of this done right it would be frankly awesome it's the only scenario where Dropout protection shines.

4. Use as lightweight CPU friendly plugins and VIs as possible (ok that's not always fun!)

5. Don't add track, bus and send FX until mix stage

Freezing VIs as soon as possible is the best option where possible though and If you are doing this it's often best to just turn dropout protection OFF as it's not required and often reduces the performance of your PC.

Good luck!

That advice is all good and well but I’d like to see them improve this. It is clearly not working well comparatively. I told you DP was working well back then but my tests were limited and overtime I realized that was an outlier- average performance has turned out to be poor to subpar at best.

alancloughley wroteBEST LOW LATENCY PERFORMANCE IS NORMALLY ACHIEVED WITH DROPOUT PROTECTION TURNED OFF NEVER TURN IT ON BY DEFAULT ONLY TURN IT ON AFTER YOU EXPERIENCE DROPOUTS

Yeah it looks like everything is on one core. How do I disable dropout protection all together? I see the minimum option, but am missing the 'off' option.

I'm using 7980xe's OC'd to 4.4, so not much upward mobility in terms of upgrades there...

The interesting thing is it seems that when bussed, and having FX, quite a bit more than necessary is getting pushed into the low buffer. Disabling inserts on tracks that aren't armed makes it work better. And on the other hand I can create a blank track, and put what I need to in there in terms of inserts (like everything that would cumulatively be on a bus and fx sends) and it plays back fine.

This suggests to me that it's shifting a lot of stuff to the one core, low buffer, that doesn't need to get shifted to there. Also it suggests that the core engine is working really well actually. I'm anxious to see what it can do with no dropout protection.

Thanks

ryanconway1 wrote

alancloughley wroteBEST LOW LATENCY PERFORMANCE IS NORMALLY ACHIEVED WITH DROPOUT PROTECTION TURNED OFF NEVER TURN IT ON BY DEFAULT ONLY TURN IT ON AFTER YOU EXPERIENCE DROPOUTS

Yeah it looks like everything is on one core. How do I disable dropout protection all together? I see the minimum option, but am missing the 'off' option.

I'm using 7980xe's OC'd to 4.4, so not much upward mobility in terms of upgrades there...

The interesting thing is it seems that when bussed, and having FX, quite a bit more than necessary is getting pushed into the low buffer. Disabling inserts on tracks that aren't armed makes it work better. And on the other hand I can create a blank track, and put what I need to in there in terms of inserts (like everything that would cumulatively be on a bus and fx sends) and it plays back fine.

This suggests to me that it's shifting a lot of stuff to the one core, low buffer, that doesn't need to get shifted to there. Also it suggests that the core engine is working really well actually. I'm anxious to see what it can do with no dropout protection.

Thanks

I'm not entirely sure if I understood your statement about "one core" correctly but the monitored chain is always on a single core. Always. That is not the problem. The problem with Dropout Protection is for some reason, there are situations where something will run absolutely fine at a Low Block Size and "Minimum" DP that ceases to run properly at the same Block Size with "Maximum".

Only mentioning this because many past discussions/FRs regarding dropout protection have resulted in no improvements to the engine when they got derailed on the question of why the full monitored chain has to be on one core.

There's not really a way to turn off Low Latency Monitoring, it's part of the audio engine but when it gets used depends dynamically on your Block Size and the Dropout Protection setting. Minimum makes it get used the least.

There are two independent settings to turn dropout protection off.

You can turn it off for virtual instruments in the Options > Audio settings there's a check box.



For normal audio tracks when the dropout protection is set to a value higher than the device block size a Z icon appears on the 2bus (main output channel) You can click on this to turn dropout protection on and off, When it is green dropout protection is on for Audio,.



These two settings are independent as mentioned so you can turn them on and off for each type of track,

If the device block size (on the first tab in Audio settings) is greater than the dropout protection level buffer the Z icon on the 2bus won't be available and you can't switch dropout protection on.

Try it out and see if you can get more instruments running on your mix with it turned off or on.

ryanconway1 wrote

alancloughley wroteBEST LOW LATENCY PERFORMANCE IS NORMALLY ACHIEVED WITH DROPOUT PROTECTION TURNED OFF NEVER TURN IT ON BY DEFAULT ONLY TURN IT ON AFTER YOU EXPERIENCE DROPOUTS

Yeah it looks like everything is on one core. How do I disable dropout protection all together? I see the minimum option, but am missing the 'off' option.

I'm using 7980xe's OC'd to 4.4, so not much upward mobility in terms of upgrades there...

The interesting thing is it seems that when bussed, and having FX, quite a bit more than necessary is getting pushed into the low buffer. Disabling inserts on tracks that aren't armed makes it work better. And on the other hand I can create a blank track, and put what I need to in there in terms of inserts (like everything that would cumulatively be on a bus and fx sends) and it plays back fine.

This suggests to me that it's shifting a lot of stuff to the one core, low buffer, that doesn't need to get shifted to there. Also it suggests that the core engine is working really well actually. I'm anxious to see what it can do with no dropout protection.

Thanks

See my later post below for how to turn DP on;/off see if it makes any difference.

I upgraded to the latest release last night ran another test. It looks like the latest releases have show a marked improvement in overall AND dropout protection performance with VIs. Switching it OFF now makes the situation worse! I'm on Windows though so it's worth trying on mac.

Core CPU distribution is still not very good overall but it looks promising and hopefully that will be improved soon too.Latency and core usage are not the same thing but some cores are running very high compared to others.

Good on them though they're obviously working on it, great to see some progress

alancloughley wroteI'm on Windows though so it's worth trying on mac.

Original poster said it works worse on Mac than windows.

That’s my experience as well.

The songs you sent me months ago that we found ran significantly worse with Dropout Protection enabled still run just as badly, as do other ones other users have sent me, even though I'm accustomed to working around it.

Thanks guys, I'll play with this some more-

niles wrote

robertgray3 wroteI agree but I’m still going to keep using Dropout Protection. It is a flagship feature and there is room to improve it, even though it is surely annoying to them that we’re not all just using Mai Tai and Presence exclusively Apparently from what the OP says the similar schemes in Logic, Pro Tools, and Cubase work better and do a similar thing.

The same issues also happen with Mai Tai and Presence. At its core working with a time critical and less time critical path is a nice idea. But the concept to duplicate the entire monitored chain to a time critical path, just isn't working very well in practice.

I'm not a software engineer but I could imagine it would work less aggressive but probably better when the monitored/armed path is dynamically using the time critical path up until the point where it meets a signal from the less time critical path again. And since the less time critical path isn't realtime, why not pre calculate its outcome before playback?

Still it would not work for everyone or every situation. Cubase's ASIO Guard does not work for everyone either. It's a band-aid for insufficient processing power to stay compliant to the user who asks too much from his system.

Cubase has some issues on windows with mmcss scheduling.. that's a talk for another time..

I can confirm cubase is behind Logic and reaper, but it's performance on mac is still far ahead of S1.. In cubase when record arming tracks at a 128 buffer it outperformed S1 by 5x (number of plugins).

TNM wroteCubase has some issues on windows with mmcss scheduling.. that's a talk for another time..

The MMCSS issue is pretty system specific (versions prior to Cubase 10 that are using over 14 logical cores for Cubase on Windows 10) at high system load, regardless of the ASIO guard setting.

TNM wroteWhat Presonus added in 4.5, was the ability to process each channel of a multi timbral plugin on a different processor thread.

No that is not correct. In 4.5 CPU performance for Multi Instruments (Studio One's native instrument container to combine instruments) was improved.

At this point multi timbral instruments run on a single core in Studio One, regardless of how many channels are active from that instrument.
Only when a multi timbral Instrument manages its own multiprocessor support, the load will be divided across multiple cores.

So if you want to benefit from multiple cores in Studio One when using a multi timbral synth, you should make sure multiprocessor support is enabled in the VST instrument itself. Or disable multiprocessor support in the instrument and run single instances of the multi timbral instrument (treating it like mono timbral instrument).

This last option is also advised by Steinberg when using their equivalent of dropout protection. Since all channels of the multi timbral instrument will be shifted to the time critical path when monitoring, which can cause large differences in CPU use (one of those cases where ASIO Guard doesn't work for everybody).

So finally got a chance to work with this a bit more, and do an actual session with S1.

When I try to set the protection buffer, to lower than the block size, I got a lot of overall system latency. I only tested with VI's, and I'll play some more, but that didn't work for me. Also I'd like to be recording vocals at 32 samples or even 16...

On my system, it's really VI's in the context of a larger template that are the issue. In fact it doesn't really seem to matter how big the template is per se. Just once it is over a certain size, I have to set the block size all the way up to 128 to get glitch free.

OTOH, when recording a mic, I can then set the block size down to 32 and it works. The only glitch I get in playback is the actual moment that recording starts. This is ameliorated by getting rid of the pre-roll and just starting recording that much earlier.

This behavior is weird to me, because many of these VI's shouldn't be using much CPU (IE battery, or Kontakt). Especially when S1 is adding another 64 sample buffer to the VI's.

Overall though, this is pretty workable even though I would prefer if I could set the buffer a little lower for VI's. Ideally I'd like to leave it set to 32.

ryanconway1 wroteSo finally got a chance to work with this a bit more, and do an actual session with S1.

When I try to set the protection buffer, to lower than the block size, I got a lot of overall system latency. I only tested with VI's, and I'll play some more, but that didn't work for me. Also I'd like to be recording vocals at 32 samples or even 16...

On my system, it's really VI's in the context of a larger template that are the issue. In fact it doesn't really seem to matter how big the template is per se. Just once it is over a certain size, I have to set the block size all the way up to 128 to get glitch free.

OTOH, when recording a mic, I can then set the block size down to 32 and it works. The only glitch I get in playback is the actual moment that recording starts. This is ameliorated by getting rid of the pre-roll and just starting recording that much earlier.

This behavior is weird to me, because many of these VI's shouldn't be using much CPU (IE battery, or Kontakt). Especially when S1 is adding another 64 sample buffer to the VI's.

Overall though, this is pretty workable even though I would prefer if I could set the buffer a little lower for VI's. Ideally I'd like to leave it set to 32.

Seems to match my observations in previous posts on this thread at least on Mac

Works excellently for audio. For virtual instruments it ranges from “not noticeably bad” to “bafflingly awful”

robertgray3 wrote
Seems to match my observations in previous posts on this thread at least on Mac

Works excellently for audio. For virtual instruments it ranges from “not noticeably bad” to “bafflingly awful”

After playing with this more, it seems that busses are the problem. When I setup a project with all the drums to a drum bus, instruments to their bus, and vocal to their- this is when the low latency monitoring falls apart. Once things are routed back to main, it's not a big issue again.

It's weird because it can have the same send FX either way, which is what I would think would be using the CPU the most...And the bus itself doesn't have to have any FX on it to cause this.

I want to dig a little deeper, but this seems to be the issue that I'm running into at least.

One thing that is hardly mentioned is drivers. Drivers are a major factor. I've had dodgy drivers before that caused a massive delay when arming record. You may have a great OS and software but if you have poor performance with your driver's, then you have poor performance. You can't assume that's the drivers work well either just because it works well on another application. They may be calling the libraries in a different way. That scenario is almost impossible to identify.