All, any idea why I would be seeing crazy disk spikes on my SSD (c drive)? This is occuring without a project being loaded. As soon as cubase starts up I’m seeing spikes to 100% on my NVMe SSD (a samsung SSD970EVO 1TB). The only disk usage in task manager is cubase.
I’m using cubase 11.0.41 on windows 10 21H2, intel 10940x, 32gb ram
Ok… sysinternals, specifically process monitor points to cubase writing over and over to …\Sonarworks\Sound ID Reference\Plugin\cfg.json. I do use the latest sonar works as a plugin in the control room.
As a test I disabled control room and the disk usage went from 100% to basically 0%. As soon as I re-enable the plugin the disk usage spikes right back up. So looks like there is an issue with the sonarworks sound id reference plugin when used as an insert in the control room.
Now the real question is if this is a sonarworks issue or a steinberg issue…
As soon as I removed the sonar works plugin from the control room insert the disk usage also goes to 0
So the pattern seems to be if the plugin is loaded in the control room when cubase starts there are disk usage spikes, if the plugin is removed and readded the spikes are gone unless the plugins interface is opened. If the interface is opened the disk usage spikes come back.
I’m using version 5.2.1.3 of their plugin
Interesting. I’ve not noticed this and I use this exact setup too. However it would be good to get to the bottom of it.
Have you reported to SW?
Sounds like something for SW. I know you wouldn’t do this in practice but what happens if you insert it on the master
I have put in a ticket with SW, so far no response yet. I am seeing the same thing if it goes on the master bus. If I add the plugin to the master bus its ok until the plugin interface is opened and then it goes crazy writing to that same file over and over. So it doesn’t seem like adding it to the master bus can be used as a work around.
Only work around that I’ve found is to load a project, remove it from the control room, add it back and assume its got the write curve loaded…
I’ll double check this.
EDIT: Ok checked this and not seeing regular writes to that file:
%LocalAppData%\Sonarworks\SoundID Reference\Plugin\cfg.json
(You can use %LocalAppData% to reach your AppData > Local folder btw)
It seems to write when Cubase/Nuendo are opened and then again on close.
I tried a few things and SW did not seem responsible for any issues. I have two instances in CR (monitors and cans).
However, of course this should be followed up and if you have any specific way of making the issue happen do let me know, happy to check.
P.
If necessary, I can provide the SysInternal logs which I gave to sonarworks, that explicitly show the continual writes to cfg.json in the sonarworks directories. What I need is someone to take the issue seriously.
I’m so glad someone else is having this issue.
I’m on Reaper and I have the same issue with SoundID causing the disk usage spike up to 100% which then consistently causes my whole DAW and pc to freeze.
I also have a Samsung Evo SSD 2tb which has more than enough speed for Sonarworks to do what it needs to do.
I noticed that the issue only happens when the calibration profile is loaded into SoundID. Try it for yourself. Unload the calibration profile and look at the disk usage. It should go down to 0.
This also only happens with the VST version and not on the standalone app.
If you find a fix please let me know. Thank you!
I FOUND A FIX!
Go to “C:\Users"Your User”\AppData\Local\Sonarworks\SoundID Reference\Plugin" in file explorer
Right click cfg.json and click properties
Then check the box “Read-only”
This will prevent SoundID from rapidly writing to this file and your disk usage will be 0%
Note: You can still change settings in your SoundID without saving to the cfg file, but your changes will not persist on the next VST restart.
If you want a change to persist on next restart then uncheck “Read-only” and then re-enable it.
Please let me know if this worked for all of you!
Thats not really a fix! When those writes fail on cfg.json they are being logged to C:\Users<user name>\AppData\Local\Sonarworks\Logs\SoundIDReferenceVST 05.02.2022 08_13_00 instead. But because of the wonky programming in the plugin those writes all appear once cubase is closed and its a lot of them so they are being buffered somewhere, I suspect using cubase for a few hours would likely end up with a crash.
The only work around I’ve found is to remove the plugin and add it back. DON’T open the plugin’s interface or the writes the cfg.json start going crazy again. This means a lot of the functions like changing curves and listening on other speaker simulations are a total pain.
Sonarworks support isn’t taking this issue very seriously, I need other users to report it as well. They are obviously more concerned with the nonsense of getting sound reference into various pieces of hardware no one uses.
You’re right I just saw that.
I disabled the write permissions to the logs folder on top of the cfg.json file and I think that fixes everything for me.
I also submitted a ticket with Sonarworks, so I hope they fix it soon.
I’ve found another clue which I forwarded to sonarworks. If I add the plugin and select the flat (calibrated) curve or the customer curve target its fine, there is one set of writes to cfg.json and then it stops. The disk writes go crazy if I select a Translation target curve like Car2 (which I have marked as a favorite).
Why it writes like crazy on opening a new project where I didn’t have the translation target selected when I closed down the project is odd.
They released a new update to SoundID today
Did it fix the issue?
I also have this problem! Using MacBook Pro M1 Max on macOS Monterrey. Any updates?
Hey guys,
I am a User Researcher in Sonarworks and can give you some good news.
The issue has been identified and should be fixed in the following update. However, I cannot yet give you an ETA on the release. It should be available on May 2022.
As you assumed it was related to continuous update of the Configuration file when in custom target mode which is why the issue is not present when restricting write permissions of the file in question.
Awesome! I appreciate you guys looking into it and finding/fixing the issue, having that fixed will definitely help out.
Still waiting for that update.
Also, I’m wondering though why you haven’t mentioned this problem under “known issues”, who knows how much SSD’s are getting destroyed because of your software.
Hey Billy,
Thanks for your concern.
The update with the fix is already available!