Currently, my issue is this: In a brand new Splat project (started back in late April) I've been producing with a client, I started having serious issues with responsiveness (things like Record arming, recording, playing back and stopping while tracks are armed), and memory leak issues, tons of static when i'm trying to play the project back at low-sample buffers for the client to hear their voice processed through my "tracking" signal chain I've built custom for this project.

Our first recording sessions went swimmingly. I could record at 48-sample buffer with my RME Fireface 800 ASIO drivers just fine and SPlat behaved perfectly. I always manage my session well, bouncing and freezing where necessary to keep CPU usage in the live-tracking realm at all times until we're done with production. This includes committing to Region FX passes as soon as they're done - melodyning, vocalsync, etc..

Last week I decided to grab the update for Splat 22.07 (updating from the 22.06 which was completely stable). Then, that Thursday some ugliness started to rear it's head when we tried to track some updated verses with the client. Static was the only issue I had noticed then but I wasn't paying attention to the memory usage bar in the command module then either. I simply kept disabling plugins I normally didn't have to disable, and eventually the static was at a "manageable" point we just started recording with it - it wasn't IN the recording, just the playback.

There really wasn't much I could disable, and what I did disable didn't really solve the problem. Plus, the client had to basically record "raw", with natural monitoring instead of through the vocal chain I had set up for him.
Well, this week it kept getting worse when I had to return to the project with our female vocalist. I had no time all weekend because of my other job to come in and try and test and benchmark changes to get the system back to working order like it had before.

Half way through the other night's session we shut it down, the singer wasn't feeling well anyway and the whole vibe was just thrown off. I had managed to get rid of the static issue by changing my Thread Scheduling Model from 1 to 2 (since I have 12 cores the extra worker thread should benefit). We tried working but Sonar kept dropping out and shutting off the engine while we were trying to record and playback. Little tweaks I made to the Preferences during the session (hurriedly, I might add) seemed to produce immediate improvements, like changing my Read and Write buffers (not enabling cache, just the buffer size dialogs) from 256 to 512... and then 1024... But those changes overall ended up NOT being solutions to the issues I'm still having.

After we shut the session down, I uninstalled Sonar completely and installed 22.06 and tested. I tested and tested and tested. No improvements. I couldn't even "update", as I don't prefer using command center since it doesn't let me CHOOSE my install location. Then again, trying to install 22.07 from a manual download on the Cakewalk site produced the same problem. I uninstalled 22.06 and then installed 22.07 BACK onto my system, tweaked, re-set AUD.ini and manually put things I knew I needed to configure again back to the way I preferred. I then went through and uninstalled and reinstalled my Fireface drivers.
I've opened up several other projects during this whole process and found only a COUPLE other projects that do the memory leak issue, but not all of them. So far, my lowest common denominator seems to be Pro-Channel EQ (current) as this is the only thing each of those projects misbehave on but I still haven't eliminated other possibilities.

What's peculiar is this. What causes the memory leak to begin in this projects? So far, it's extremely noticeable when I try to open the projects with my sample-buffers set to 48 (sessions at 48k/24bit). Within 30-45 seconds as long as the engine is "enabled" the memory fills up. I opened up a project at 96k/24bit that was from my weapon handling sample editing projects and there's some plugins on the master for previewing purposes. I added a new audio track and enabled input echo. I hit play... The buffer issue didn't occur at all. Okay, must be a plugin or several...

Now i'm back in my main client project, with a track armed at the maximum sample buffer, and even with the session stopped but the engine live the buffer is just SLOWLY filling up. I can play the project, but if I stop... it becomes unresponsive for a bit and the memory usage drops back to a more nominal level, and starts building up all over again. If I disarm the track from record-enable but leave input echo on? The memory usage goes right back to the very BASE at which I opened the project, and never climbs.

Now here's the really clever part, I set my sample-buffer BACK to the absolute minimum with no tracks record-armed, and I can play back smoothly. No memory leak, no glitches or static (audio dropouts). In fact, I can literally turn on EVERYTHING in my mix chain that I turn off for the vocalist to track with (including the VERY CPU intense 2C Audio Aether plugin, which is on an Aux Return track their vocal group busses have "sends" to) and yet no dropouts, and completely smooth performance.
So far, best performance I've had non-record ever, and that's just from switching my Thread Scheduling Model from 1 to 2, and then playing with my Extra Plugin Buffers, currently at 4 but I may set it back to 1 just to see how the performance changes.
Now I must go through the very time-consuming process of Safe-opening the project and figure out which of the plugins/PC Modules are the culprit(s).... Especially because this project is going to be our base for creating project and track templates on upcoming work :/
Note: Just tonight my workstation upgraded the Win10 Anniversary Release.  I've been trying to open the project and test for changes in behavior but it still persists.


Just to get through the tracking phase though I'm going to have to create a new project with the instrumental rendered out and just record 2-track style. Once I'm done with the tracking I can do my editing and melodyne corrections, bounce those Region FX and just copy pasta the track back into the original...

System Specs:
CPU - Intel i7 980 Xtreme
RAM - 16 GB G-Skill Ripjaw series
MOBO - Asus P6x58d Premium
GPU - EVGA Geforce GTX 560
OS Drive - Samsung EVO  850 500gb SSD
Apps Drive - Corsair 128gb SSD
Storage Drive 1 - Western Digital Caviar Black 2tb
Storage Drive 2 - Western Digital Caviar Black 2tb (Projects drive)
Storage Drive 3 - Western Digital Caviar Red 4tb
Storage Drive 4 - Western Digital Caviar Black 2tb
Storage Drive 5 - Western Digital Caviar Black 2tb
Optical Drive - LG Super multi Bluray burner drive (Sata)
Audio Card - Creative Labs SoundBlaster X-Fi Fatal1ty Edition (PCI)
Audio Interface - RME Audio Fireface 800 (Driver version 3.116, hardware revision 2.77)

It is not fair to claim Sonar has a memory leak as if even one party plug is loaded, be it a control surface plug or vst or otherwise, that one errant plug can cause SONARxxx.EXE to grow in terms of memory consumption. Now, as you claim, Sonar may have a leak but you know thems fightin words. :-)

Depending the plugs loaded (to hear their voice processed through my "tracking" signal chain I've built custom for this project) you may have to increase buffers. It's a way of life.
 
If you need some tracking FX maybe your RME supports the use of their MixControl software. That way you can keep buffer low for tracking (while disabling your signal chain), then enable your signal chain and buffers before a playback for the client.
 
Without sounding condescending, you really need to know the limitations of the plugs you use and try not to expect all your plugs to work at low buffers.
 
Using my RME UFX, I typically track at 64 buffers WITH NO FXs enabled. Then when I'm ready to mix I lay em on and raise my buffers to 2048. But, I have no clients to please, just me and I'm easy.

I would also like to add that you'd be hard pressed to prove to Noel Borthwick (CW CTO) that SONAR itself has a memory leak.

I hope your soundblaster is disabled completely when using the RME and that its drivers are not in conflict with said RME.......

Cheers,
J

joakes
I hope your soundblaster is disabled completely when using the RME and that its drivers are not in conflict with said RME.......

Cheers,
J

Where's CJ when we need him?

joakes
I hope your soundblaster is disabled completely when using the RME and that its drivers are not in conflict with said RME.......

This is the first thing I would try. I'd do a system restore and not just disable, but uninstall the SoundBlaster and run a few tests. 
 
As for memory if you're using Kontakt don't forget about purging memory with various instruments.

Wow thanks for all the replies.  I've gone through and restored back to the week's previous Backup of WIndows AND my Apps drive (no change in plugins though). Re opened the project and the same behavior persisted.  I've since updated Windows 10 with the Anniversary update, and at least the memory leak doesn't cause Sonar to just blatently drop out. 

I've never, ever, ever had a problem keeping the SoundBlaster card enabled while using Sonar, and there was literally zero changes between the prior Thursday's session and Tuesday's shut-down that happened with the client.  The chain WAS stable and operating fine.  I've done MEMTESTs and benchmarks and I have HDTune Pro just to check SMART status and benchmark all of my drives to make sure there were no obvious bottlenecks in the hardware like a sata cable dying for whatever reason.  I even moved the project to my OS drive (SSD with TONS of free space) and no change.  That said, I've gone in and disabled (in windows Device Manager) the Creative Labs SoundBlaster, as well as all of Nvidia's HD Audio devices..  Again, no change.

I've already submitted a manual support ticket so hopefully whatever is going on the support team can help find it.  I doubt it's anything FIRST party with the DAW itself but seeing as how I've been able to record and monitor through Processing chains for years without trouble at 48-sample buffer with a 48k/24 bit session not even causing my CPU / memory to break a sweat, it's behavior that is standing out like a sore thumb.

I just spent the better part of 7 hours saving out a copy of the project to go through with a fine-tooth comb, deleting plugins and pro-channel modules until I had literally NOTHING left but the Pro-Channel EQ's - which cannot be removed from the channel strips.

Now i'm going through and unfreezing the vocal tracks that are DONE and deleting take lanes, reducing the clip/audio file load..  All melodyne and vocalsync region fx are bounced immediately after editing so they're nothing more than audio clips on the timeline.  Audiosnap has never been invoke.  There are no live VSTi's,  everything is always frozen, or bounced and archived and/or deleted to keep the project nice and tidy (that I don't want recallable later for session and track template creation).

I bring that up specifically because I've spent over a month on this project working closely with the artist developing a specific sound - hence the custom processing chains...  The artist and I are using this first song's session project as a baseline for building upcoming projects later and thus a majority of just about everything we're doing in here needs to be recallable.  I always "deconstruct" a completed project afterward, bouncing out stems, tracks, clips, and then saving Pro Channel Chains, FX Bin Chains, Track Templates (multiple variations if necessary), and Project Templates (multiple variations) to make starting new projects with the same feel and vibe and possibly even instrumentation where necessary as quick as possible.  I've worked this way for years without complaint and it's one of the greatest boons to working exclusively in Sonar!  Just sucks when I run into little hiccups that get blown out of proportion (like nasty static, memory filling up and dropping the audio engine out... or NOW, just dealing with static creep after the memory hits its ceiling and dumps a chunk and begins to fill again).

Update: Now completely removed everything.  The very last leg of my deduction process leaves only the Patch points themselves connecting to the aux tracks, which are completely devoid of any processing.  Memory continues to fill and static creep begins when the memory hits the ceiling and starts purging and re-filling.  I'm utterly stumped :(

UPDATE:
Alright... last trick up my sleeve.  Someone in the Cakewalk Sonar User Group on Facebook  mentioned they noticed when they happened to do a Compatibility check in Windows 10, that Windows suggested to run in Compatibility mode for Windows 8.

 

Just now testing this...  Dunno why I didn't think of it sooner.

 

HOLY CRAP.  NO MORE MEMORY LEAK!  NO MORE STATIC CREEP!!!  That just solved everything. 

Going through and re-enabling as much as I can just to test drive and I'm able to have my complete processing chain live without issues.  So odd.