Morticia wrote

When you say performance do you mean ability to play many tracks/plugins or latency?
Hardware latency is not improved. Just the ability to work with it.
Yes, I do know that hardware latency cannot be improved by software
Yes I know you know that. Many assume it does.

I have had to increase my interface audio buffer size in my interface significantly,
thereby increasing hardware latency, in order to just play back a song comprising of just 20 audio tracks with trivial plugins (channel strip, eq, comp, a couple of reverb / delay busses) without drop-outs and glitches.
This is contrary to all testing. I wonder why?

The very same project can be played back fine on the lowest possible interface audio buffer setting in V.3.3.4 without any problems.
Can you zip the song up or a cut down version that still exhibits the same behavior?

In both S1 versions the system CPU utilisation, measured in Windows Performance Monitor (not the S1 thing), is around 30% - ish

Basically as it stands, V 3.5 is unusable for me.

I will post more details when I have done some structured analysis and captured some
performance counters.
OK but I am more concerned with the paramter asked for in the DP LLM thread.
Which is where we probably should move this.
Anyway the song PM to me would be great.

Not sure if it is jpetit or one of the dev team (Ari ?) who amended my OP to include their reply
However, I think have tracked down the issue: The device block size setting was not the same as the size of the audio buffer in my interface ( probably my oversight ) in V 3.3.4 I had this 'locked' to the hardware buffer - can we have that lock feature in the next update please ?

I have now made sure that they are both the same size and all seems to be well so far. Yay !

Hardware monitoring is slightly better than the low latency monitoring and the song appears to play without drop-outs and glitches
Midi input to a virtual instrument works well with no noticeable latency.

Yes by all means please move this to the DP LLM thread.

Thanks

mikemanthei wroteI'm getting noises when using fader automation on the master fader... The noise is essentially the audio at 0 db. (no attenuation) for a very short amount of time. The shortness of the error makes it sound a bit like a "pop".

Anyone else seeing this?

Here are some particulars to this:

When I set Dropout Protection to Minimum or Low, I don't get noise/popping..
When I set Dropout Protection to High or Maximum, I do get the issue.
I also have "Process Precision" set to 64 bit, and when I set that down to 32 bit, the problem is at least lessened...if not removed.

It's fairly easy to replicate.

Drop some audio to a track.
Create some automation on the master fader. I used a very slow (30 second) fade out and back in using only 3 automation points.

The issue will present itself on both playback and the resulting mixdown file.
It happens with or without a control surface present.

I haven't yet tested whether this happens on channel automation too, I only had a short time to test it today.

jpettit wroteDo you think the key to this is 64 vs 32 bit Process Precision?

BojanKerkez wroteAfter three days of trying out various settings on both my (mediocre) soundcards, I still haven't found a usable combination for this new feature, because when "Enable low latency monitoring for instruments" is checked and Dropout Protection set to anything above Low, I cannot switch between tracks without sound cutting off and the first core CPU load almost doubling.

BojanKerkez wroteAnd in more complex songs, especially when DP is set to Maximum, the CPU metre is usually stuck at 100%. This is regardless whether Process Precision is set to 32 or 64 bit, though with 64bit it is worse.

BojanKerkez wroteA soundcard with better drivers would probably solve this for me, but I just cannot afford one at the moment or in the foreseeable future.

niles wroteThe sound being chopped off when switching monitoring sources unfortunately is normal behavior with DP and LLM for instruments (very annoying).

niles wroteIs that with or without monitoring a track?

niles wroteDo you happen to use instruments with multiple outputs (Kontakt, Battery, SampleTank, Halion, Falcon etc.)?

niles wroteI doubt it.

niles wrote

BojanKerkez wroteAfter three days of trying out various settings on both my (mediocre) soundcards, I still haven't found a usable combination for this new feature, because when "Enable low latency monitoring for instruments" is checked and Dropout Protection set to anything above Low, I cannot switch between tracks without sound cutting off and the first core CPU load almost doubling.

The sound being chopped off when switching monitoring sources unfortunately is normal behavior with DP and LLM for instruments (very annoying).
The high load depends on what channel is monitored (how many inserts loaded, if it's a multiple out VST etc.).

For instance I have a sound card with decent drivers (RME) however when I monitor a Reaktor channel, while DP and LLM is enabled, the CPU strain is far more higher (doubled) than setting DP to Minimum (or 3.3.4). The DP tech just isn't very suitable for monitoring high usage instruments because the load of a monitored instrument (+ its channel inserts) is temporarily doubled.

BojanKerkez wroteAnd in more complex songs, especially when DP is set to Maximum, the CPU metre is usually stuck at 100%. This is regardless whether Process Precision is set to 32 or 64 bit, though with 64bit it is worse.

Is that with or without monitoring a track? Do you happen to use instruments with multiple outputs (Kontakt, Battery, SampleTank, Halion, Falcon etc.)? DP does not play nice with them when monitoring a track connected to the first channel of a multi output instrument because all channels + their inserts will (also) be placed in the low latency path.

BojanKerkez wroteA soundcard with better drivers would probably solve this for me, but I just cannot afford one at the moment or in the foreseeable future.

I doubt it.

However, I think have tracked down the issue: The device block size setting was not the same as the size of the audio buffer in my interface ( probably my oversight ) in V 3.3.4 I had this 'locked' to the hardware buffer - can we have that lock feature in the next update please ?

I have now made sure that they are both the same size and all seems to be well so far.

C.LYDE wroteConsidering the length of this topic, I'm not sure what value this comment will have.

since upgrade CPU spikes are terrible.

In comparison to Cubase 8.5 and Reason 8.5 running on the same machine - S1 behaviour is completely confusing, since I was expecting better, more stable performance.

scottmoncrieff wroteYou using Reaktor at 176 Khz ?...If you change that to a more reasonable 44.1 Khz, you'll see a massive difference in CPU usage..

Anyways I decided to do my first little test with Reaktor's Rounds and various settings with Studio One 3.5's new options.

Morticia wrote

However, I think have tracked down the issue: The device block size setting was not the same as the size of the audio buffer in my interface ( probably my oversight ) in V 3.3.4 I had this 'locked' to the hardware buffer - can we have that lock feature in the next update please ?

I have now made sure that they are both the same size and all seems to be well so far.

It seems I spoke to soon.

Although this improved things, I cannot play back anything that I have recorded using previous versions of Studio One without getting at least one drop-out or audio glitch, unless I set my audio interface buffer to a minimum of 512 samples. Even if I have saved the song in the new 3.5 format. I can play them all back without drop-outs in V 3.3.4 with the audio buffer at 224 samples in my interface.
<== this is where my 60,000 user 59,999 configuration comment on day one comes in.
Remember we did a specific fix to your interface back in 3.2 i think, so my point there will be corner cases.



No problems with stems exported from S1 and imported into Sonar either. Funnily enough Sonar will use more CPU than S1 3.5 (average about 10% - 15% more) yet is far more stable regarding drop-outs than S1 V3.5


I have tried using the ASIO4all driver instead, it makes not a jot of difference.
I have tried every combination of DP / LLM parameters, likewise no difference.
<== sure you were just testing your driver but lets keep it simple.


I am on the point of un-installing V 3.5 as it is unusable.
I don't see much point in sending in a song to jpetit as requested, as this is affecting * all * S1 songs with more than a couple of tracks.
<== You know I was expecting it to run fine on my system but this just help to isolate the variable.

I notice that in the V 3.5 official discussion thread there is another user with Win 8.1 and a Roland interface with the same issue -

C.LYDE wroteConsidering the length of this topic, I'm not sure what value this comment will have.

since upgrade CPU spikes are terrible.
<== this one as noted over there needs at least 6 parameter reported to proceed bu t the Win 8.1 has been noted

In comparison to Cubase 8.5 and Reason 8.5 running on the same machine - S1 behaviour is completely confusing, since I was expecting better, more stable performance.

I have run some side by side Windows Perfmon traces whilst playing back the same song in both versions and have noticed that the amount of disk reads / sec on the system drive are about 3 times as high in the V 3.5 trace compared to the 3.3.4 trace. Is this expected ?
<== no just better core Balancing and thread counts.

scottmoncrieff wroteYou using Reaktor at 176 Khz ?...If you change that to a more reasonable 44.1 Khz, you'll see a massive difference in CPU usage..

jpettit wroteThanks Niles.
I guess I'm losing track of the issue.
Instruments cutting out when you switch between monitoring two different instruments?
What is the purpose of that workflow?

jpettit wrote Was that the point of the OP on this issue?
I thought it was a switching thing.

BojanKerkez wroteI cannot switch between tracks without sound cutting off and the first core CPU load almost doubling.