Fender Studio Pro 8.0.2 - Discussion Thread

[Number6]

Confirmed Bug by QA:

Confirmed Bug: Controllers don't arm correct tracks when using folders

This is an issue since the beginning of time it seems, and I can reproduce this issue in 8.0.2 Windows (unfortunately!). If somebody could try to repro this with any Faderport or Mackie or Atom SQ (Song Button -> Page 2 - Rec) that would be great - thx! Here are the steps to repro: Create say...

studiooneforum.com

 

[js1]

okay, I'm now sitting at my desk after some experiments.

no matter what I do, S1v8 just doesn't work stable with a buffer size of 64 samples. once in a while there's a spike in the CPU, no clues in performance monitor, no clues in system-wide activity monitor (that's a mac) and the sound goes 'click'. just after that S1v5 on the same computer with the same projects works fine.

it's not the plugins, I can reproduce this in a project with no plugins. it happens to me at an empty project as well, I just create a new project, start the recording and it drops out once in a couple minutes. the S1v5 works fine, but not the v8. I even don't need to start the recording to reproduce, I create a track, enable input monitoring and listen to it and it will drop out.

I'm able to reproduce this on two different computers (both ARM Macs) and two different audio interfaces. S1v5 doesn't drop out while using 64 samples, S1v8 just needs it to be set to '128'. Ableton also works stable on 64 samples. didn't check Reaper, but it definitely worked with 64 samples a while ago.

user impact? uhm, monitoring latency while recording is now 5ms, not 3ms, i.e. almost twice the latency.

not sure how do I report this regression, but I'll try.

There was a change in the V7 cycle with Mac processor handling. Prior to the change, S1 only used performance core. After the change, S1 could also take advantage of efficiency cores. Sounds good, BUT...

In my case, using the efficiency cores with low latency caused all manner of spiking, even with lightly loaded projects. Which is now default setting. I disabled the efficiency cores, and I was back to running with 32 sample latencies.

If you're near the limit of processing on your project, then enabling the efficiency cores would give you additional headroom. But, you'll probably have to increase your latency.

Or, it could be something different in your case. Anyways, here's the setting:

 

[Lukas]

In my case, using the efficiency cores with low latency caused all manner of spiking, even with lightly loaded projects.

Which in fact is expected behavior.

Efficiency cores work best in large buffer scenarios. There is a high risk of dropouts when used in a lower buffering scenario. This is the reason why many DAWs don't use efficiency cores at all. They're not designed for real-time / low-latency audio.

 

[TheNeil]

Yeah, they really shouldn’t be enabled by default.

 

[LiveFromPFD]

Efficiency cores work best in large buffer scenarios. There is a high risk of dropouts when used in a lower buffering scenario. This is the reason why many DAWs don't use efficiency cores at all. They're not designed for real-time / low-latency audio.

Oh! That is so helpful to know. Thanks.

 

[Rambler]

Which in fact is expected behavior.

Efficiency cores work best in large buffer scenarios. There is a high risk of dropouts when used in a lower buffering scenario. This is the reason why many DAWs don't use efficiency cores at all. They're not designed for real-time / low-latency audio.

Isn’t that exactly what a hybrid audio engine is for - processing record-enabled tracks with the smallest buffer possible (and therefore on the p-cores) and playback tracks with a higher buffer (therefore on the e-cores)?

Since Studio Pro has a great zero-latency monitoring option with a dedicated playback buffer I don’t get why the described behavior is as expected. In case of Cubase and ASIO guard I do not notice such behavior. Efficiency cores work well even with lower buffers sizes (since asio guard adds 20 or more ms of buffer anyway except for tracks that are record enabled). Reaper with its anticipative FX processing (which excludes record enabled tracks) also does not have this problem.