Jump to content
fnordpow

SOLVED! Latency Continually Getting Longer?

Recommended Posts

Posted (edited)

SOLVED
I am using the latest CbB version available and a Focusrite Scarlette 18i20 Gen 2 (newest drivers / firmware). No matter what buffer size I set in the Focusrite Control I have this problem.

Open CwB, create new project, select input (in this case it is Left1 for input 1 on 18i20), play instrument with CbB live monitoring enabled. As I play I will hear crack / pop sounds on my studio mons. Each and every time it pops the latency gets longer. If I leave it for a few mins it will get way out of sync. I did a five minute test of just leaving it enabled and after 5 mins I had 30 seconds between playing and hearing the instrument.

LatecyMon reports all is fine with the PC, no issues with interrupts etc.

This is a new issue in the last update or two from Bandlab. It worked perfectly before. The computer is a Core i7 with 16GB ram and a fast SSD. Clean Windows install and updated. All drivers (intel etc) are up to date.  Excess processes disabled (Windows Security / Antivirus / etc).

Another test I have done was with both Reaper and Ableton. They will both track without issue and have no pops and clicks even at 64 buffer size. That is why I am leaning towards a Cakewalk issue and not hardware or drivers.

Any suggestions on what to try to correct it? I have been on Calkwalk for a long time and don't really want to fully switch to another DAW. CW is home to me for my work flow. I can use the others but they just don't feel right.

Edited by fnordpow
Issue Solved

Share this post


Link to post
Share on other sites

Any plugins loaded into your project? 

If so, which ones?

Driver Mode: ASIO?

What is your ASIO Buffer Size set to?

What Sample Rate?

What are CbB-reported latencies, shown in Preferences?

Bob Bone

 

 

Share this post


Link to post
Share on other sites

No plugins loaded in the project. 

Driver Mode is ASIO

ASIO buffers sizes tested : 64, 128, 256, 512, 1024

Sample Rate of 48k

As of right now with the ASIO buffer set to 128:
Input 6.1ms
Output 6.1ms
Total Roundtrip 12.3ms

As stated above every pop / click results in the latency to playback getting further and further behind. Yet the driver settings page shows the reported as the same values.

Share this post


Link to post
Share on other sites

Thanks - nothing out of whack with those settings.  It seems odd that were it to be something with CbB itself, we would see more reports of similar issues, but there just aren't, so I am temporarily stymied.

What do you have plugged into your audio interface?  (Mic? guitar? external keyboard's audio output?)

Is Windows maintenance completely up to date (not missing any cumulative maintenancve that might not have gotten automatically installed)?  Please go into System Information and provide you Windows Version and Build.

What happens if you just play some imported CD track?  Does it crackle every so often, or only when you have something plugged into your interface?

Here is a thread where someone had increasing latency - might be worth a read: 

https://discuss.cakewalk.com/index.php?/topic/10708-201912-major-latency-problem/

I will try to think of some other things to look at. 

Thanks, 

Bob Bone

Share this post


Link to post
Share on other sites
7 hours ago, fnordpow said:



Another test I have done was with both Reaper and Ableton. They will both track without issue and have no pops and clicks even at 64 buffer size. That is why I am leaning towards a Cakewalk issue and not hardware or drivers.

Any suggestions on what to try to correct it? I have been on Calkwalk for a long time and don't really want to fully switch to another DAW. CW is home to me for my work flow. I can use the others but they just don't feel right.

Yeah, I felt the same way about sticking with what I know, but it can't always work that way.  I have Sequoia/Samplutude Pro X now as my backup, and just added Nuendo 10.  Never, ever a glitch, although I like my familiar Cake/Sonar field of operation.  If steadiness and lack of audio struggling is needed, I'd go elsewhere.  I still use Cake, and am very pleased with the renewal of it with Bandlab, but it is second-rate for a producer in terms of audio engine lagging and odd behavior at times. I want to love it, but we have to be objective.

Share this post


Link to post
Share on other sites

Reset your config file to defaults. Thread Scheduling model of 3 is dangerous to me. I have mine at 2.

Make sure it wasn't something in your config.

Share this post


Link to post
Share on other sites
Posted (edited)

What he said. This is a known issue on some systems (including mine). If your ThreadSchedulingModel is set to 3, set it to 2 and I'm pretty sure your issue will vanish.

Edited by Starship Krupa

Share this post


Link to post
Share on other sites
1 hour ago, Gswitz said:

Reset your config file to defaults. Thread Scheduling model of 3 is dangerous to me. I have mine at 2.

Make sure it wasn't something in your config.

 

3 minutes ago, Starship Krupa said:

What he said. This is a known issue on some systems (including mine). If your ThreadSchedulingModel is set to 3, set it to 2 and I'm pretty sure your issue will vanish.

You both saved me from going insane! That solved my issue!!!! You all are great. Thanks for taking the time to help me get back on track.

 

  • Like 2

Share this post


Link to post
Share on other sites

That's fantastic, and exemplary of the help given here in the community.

I would add one thought: can the solution be explained so that we can understand the relationship of the setting to the performance issue?

That would go a long way in actually potentially arguing against my generally negative views posted here.  Let's understand the issue and learn from it, versus just changing a setting.

Share this post


Link to post
Share on other sites

The ThreadSchedulingModel parameter has to do with workload distribution of CPU core threads, and is described in the online documentation under the Aud.ini online help.

The new parameter value of '3' sets the distribution model to 'aggressive', and was indicated somewhere to potentially yield unpredictable results.  

Please note that the online documentation covering modification of the Aud.ini file quite clearly indicates that making some configuration changes can sometimes cause issues, and it recommends not modifying the file unless directed to, so from my perspective, anyone who DOES decide to modify the Aud.ini file - be prepared to undo changes, if adverse issues arise.

The ThreadSchedulingModel parameter defaults to '1', and possible values are 0-1-2-3.  Here is the online help blurb on this paramater:

"This variable goes in the [Wave] section and controls the interaction of the main audio thread and worker threads on multiprocessor systems when the Use Multiprocessing Engine option is enabled. Depending on the system, a particular model may result in less glitching and better overall performance. The values are as follows:

0 = Same as previous versions of Cakewalk.

1 = (default) Better thread balance. Model is more efficient and can provide cycles for other tasks.

2 = Additional worker thread is created. This may result in improvement with Quad processor systems or higher. Not recommended for Dual processor systems.

3 = Agressive"

Bob Bone

  

image.png

  • Thanks 1

Share this post


Link to post
Share on other sites
3 hours ago, Jon White said:

can the solution be explained so that we can understand the relationship of the setting to the performance issue

To boil it down, the user tried a performance tweak that had unintended (and unexpected) consequences.

To take a wild guess, I'd say that with the more aggressive thread scheduling, whatever thread(s) services MIDI interrupts somehow keeps missing the bus (so to speak) on certain systems, and the MIDI latency keeps adding up to the point where it's noticeable and then unusable.

I think at this point it's a "doc, it hurts when I put my arm like this" issue. Works on most systems, just not on mine. My ThreadSchedulingModel only goes to 2, but I won't worry that someone else's can go to 3. The computer is a hand-me-down,

Some might call it a throwback of sorts that Cakewalk uses and exposes such things as .INI files in this day and age, but I suppose it's the result of its long heritage. I don't know how other DAW's do it, maybe they have a program-within-the-program that scans the hardware and sets everything to what it thinks is optimal based on processor type, clock speed, amount of RAM, etc. or the engine adapts on the fly or it's just one size fits all or they do it the same way Cakewalk does, with config files. BandLab has a support staff to recommend necessary changes, anything else is optional on the users' part. It's like editing the registry: back it up and don't even try if you are not good and sure of what you are doing.

Share this post


Link to post
Share on other sites
54 minutes ago, Starship Krupa said:

To boil it down, the user tried a performance tweak that had unintended (and unexpected) consequences.

To take a wild guess, I'd say that with the more aggressive thread scheduling, whatever thread(s) services MIDI interrupts somehow keeps missing the bus (so to speak) on certain systems, and the MIDI latency keeps adding up to the point where it's noticeable and then unusable.

I think at this point it's a "doc, it hurts when I put my arm like this" issue. Works on most systems, just not on mine. My ThreadSchedulingModel only goes to 2, but I won't worry that someone else's can go to 3. The computer is a hand-me-down,

Some might call it a throwback of sorts that Cakewalk uses and exposes such things as .INI files in this day and age, but I suppose it's the result of its long heritage. I don't know how other DAW's do it, maybe they have a program-within-the-program that scans the hardware and sets everything to what it thinks is optimal based on processor type, clock speed, amount of RAM, etc. or the engine adapts on the fly or it's just one size fits all or they do it the same way Cakewalk does, with config files. BandLab has a support staff to recommend necessary changes, anything else is optional on the users' part. It's like editing the registry: back it up and don't even try if you are not good and sure of what you are doing.

The ThreadSchedulingModel is handled and managed by Sonar/Cakewalk, and they had added an 'aggressive model', that is represented by the number '3' for that parameter - where it used to have possible values of 0, 1, or 2, with 1 being the default.

The release notes for Cakewalk's 2020.01 release notes introduce the new 'Aggressive' parameter value of '3', and also quite clearly indicate that this new scheduling model is experimental, and that some folks might experience issues if using it:

From the release notes:

"Optimizations

Experimental aggressive task scheduling model

We continue to work on improving our multi-threaded engine performance and have added a new "aggressive" task scheduling model. The aggressive task scheduler utilizes more efficient task management that can result in better multi-processing and fewer thread context switches. This feature is still experimental so report back if you notice any improvements or problems when using it."

Bob Bone

 

  • Thanks 1

Share this post


Link to post
Share on other sites
7 hours ago, Robert Bone said:

Please edit your initial post, to show 'Solved'.

Bob Bone

Done and thank you for all your help as well Robert.

 

 

8 hours ago, Jon White said:

That's fantastic, and exemplary of the help given here in the community.

I would add one thought: can the solution be explained so that we can understand the relationship of the setting to the performance issue?

That would go a long way in actually potentially arguing against my generally negative views posted here.  Let's understand the issue and learn from it, versus just changing a setting.

To clarify the issue:

Opening a new project and using and audio input over ASIO with input monitoring enabled would create pops and clicks no matter the buffer size set in the ASIO device. Each click or pop would add latency to the return signal. If left long enough would add up to seconds of latency, not just milliseconds. 

I do not recall changing this setting, but reading the information provided, I must have. Or another user of this PC / DAW must have. (virtual beatings will be distributed <sarcasm>).

Share this post


Link to post
Share on other sites

So, mine is set to 1. Should I set it to 2? I get frequent, random dropouts. Might this help with that?  

Share this post


Link to post
Share on other sites
6 minutes ago, Rod L. Short said:

So, mine is set to 1. Should I set it to 2? I get frequent, random dropouts. Might this help with that?  

Well, there are other reasons for dropouts, as well.  Why don't you fire up a separate thread so we can work through it without repurposing this thread?  Kewl?  I will keep an eye out for it, and try to assist you.  I suspect there are some other things more likely to be causing frequent dropouts for you, so go ahead and post that and we can get to work fixing you up.  :)

Bob Bone

Share this post


Link to post
Share on other sites

Hi Folks, as mentioned in the prior release that model is considered "beta" since I still have to do more testing with it. 
The latency problem is due to a weird race condition leading to audio buffers being lost. I just havent had time to track it down yet but will get to it.

For now don't use that model until further notice.

  • Like 2

Share this post


Link to post
Share on other sites

Mine is set to 2...12 core/ 24 thread Ryzen 3900x .. I didn't set it to 2 though, so did CBb select it's own setting ?

Seems to work pretty well, not had any issues and all the threads seem to be doing something

Share this post


Link to post
Share on other sites
2 hours ago, Mark Morgon-Shaw said:

Mine is set to 2...12 core/ 24 thread Ryzen 3900x .. I didn't set it to 2 though, so did CBb select it's own setting ?

Seems to work pretty well, not had any issues and all the threads seem to be doing something

I changed mine, a while ago, from the default 1, to its current 2 - that works wonderfully, and my system is quite stable (haven't crashed in almost 2 years), so I am quite happy to wait for the go-ahead from Noel, before attempting to use the new value of 3 they added.  My desktop uses an AMD Ryzen 1950x Threadripper, so has boatloads of cores, and it is quite happy cranking away on the setting of 2.

Bob Bone

  • Like 1

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×
×
  • Create New...