Sonar Platinum Memory Leak and dropout issues (22.06 and 22.07)

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)

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.......

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.

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 :(

Sonar Platinum does not need to be run in a Compatibility Mode.   Whoever posted that is all wet.  It is fully Win 10 compatible. I've been running it in Win 10 for over a year.

maybe the latest driver will fix it (3118 is newer than the one you posted)? drivers were updated recently https://www.rme-audio.de/en/downloads/driver/fireface.php

Hatstand
probably a dumb suggestion as you seem to be extremely thorough, but have you run LatencyMon?

Haven't used LatencyMon in ages but I'll give it a shot again.

pwalpwal
maybe the latest driver will fix it (3118 is newer than the one you posted)? drivers were updated recently https://www.rme-audio.de/en/downloads/driver/fireface.php

Double checked it.  Windows Device Manager reports 3.1.18 while the Fireface.exe (systemdir) still shows 3.1.16, hence the version mentioned above.  I check their drive page weekly so I knew I had the latest downloaded.  That indeed may be an issue but so far Sonar is running completely stable in Compatibility mode for Win8.

I also went through every driver model available, switching from ASIO to WASAPI, to WDM/KS and never saw the stability return, the RTL just went through the roof (which would be fine if I were mixing).

still puzzled as to why win10 recommends compatibility mode - firewire chipset? (& driver?) bios? weird...

dcumpian
I will say, running plugins while tracking is a recipe for disaster. I understand why you are doing it, but I would strongly suggest that you use hardware for that until the raw tracks are recorded. Once everything is in the box, that's when you can start adding plugins to begin the mixing process.

while that's generally true, the op's issue only appeared after the 07 update

it does seem strange that it is happening in your environment. another suggestion is try running sysinternals process explorer to see if there is something else causing this in the background

For ME, ASIO wasn't an available option until I de-selected the audio device.  THEN, I could choose ASIO, which would find and auto-populate for my audio interface for ASIO mode.
 
Bob Bone
 

Are you referring to this? https://technet.microsoft.com/en-us/sysinternals/bb545021.aspx

Try creating a bundle file (.cwb) of the problematic project and then open (unpack) it again in SONAR.
 
Although you mentioned you didn't use Audiosnap (but maybe inadvertently), creating a bundle file would get rid of any AS traces.
 

Soulburned
Me too.  It's an onboard FW 400 port.  VIA chipset is reported (Driver version 10.0.14393.0). 

Pretty shocked that a board of that caliber would use a VIA cjipset for FW,   While that would most likely would not cause an issue with an RME unit you could try a pcie FW board with a ti chipset.