When I saw it, I knew there would be more than 2.
I use the manufacturerās ASIO driver. And my buffer size usually set to 256, but now i set to 512 that i mentioned above.
Should i upgrade my audio interface to the next level such us Apogee Symphony Desktop e.t.c? Would that solve my problem?
Honestly, I doubt it if the answer is to throw hardware at the problem. I have a couple of low end Behringer interfaces and a high end RMI. Thereās really not that much difference. There are a number of people here getting good results with Focusrite. And your computer (laptop?āspecs look more like a desktop) seems plenty powerful.
A few more things: how are you managing cores? Cantabile should be doing all of the core management, not the VSTs. Power interruptsāhave you gone through the Glitch Free book and made sure USB ports arenāt freezing the CPU to save power?
LatencyMon will show you where your resources are being spent had help you tune your systemās resources for live Audio. Got the latest WiFi drivers? Have you tried running with WiFi disabled? Thatās always a big target. Also, BIOS updates used to be high on the list. This is a pretty new Intel, so you probably have already checked that. Worth mentioning, though.
Process Lasso will give you a new Power Management profile. In the Tools->Optionsā¦->Audio Engine settings, hereās what I have on my Studio Machine
Sample rate of 48K is overkill, but I use that to sync up with my Kurzweil 2661. Look into Ultimate Performance and Bitsum highest performance profiles. LatencyMon will help you determine which performs best for you. (These are the Power Plans Brad referenced in the conversation, above.)
Glitching on a i9-9920X based PC? No way! I think you have a serious problem with Windows drivers. Richard hints are perfect. Try to run LatencyMon (post a screenshot) after you set power plan to high or ultimate. Here the steps:
Reboot PC.
Wait a bit after login.
Run LatencyMon (donāt run any other program).
Click on play button and wait at least ten minutes.
Let us know the result. This is the first important step to detect the source of glitches.
Iām with Rackedbrain- itās not a hardware issue, itās configuration. Somewhere, something is hogging resources. We just have to determine what. Iāve run on a laptop with probably a fourth of those specs and a 1st Gen Focusrite and been able to run dozens of VSTs.
That reading can be difficult to track down as to the cause, as the dxgkrnl and ntoskrnl are the main parts that all those externals run through, so it doesnāt tell you anything about which driver might be the culprit.
I went into the device manager and loaded every single driver in the list and clicked the āUpdate Driverā button in the Drivers tab for each. I was really surprised by which drivers were needing updating. I just updated them all that had updates available and was relieved to see my system magically pass the test. So give that a try.
Terry
Hello,
I realise this is an old thread but Iām struggling with this same type of issue.
Basically, some VSTs such as Serum and Padshop are almost impossible to use because they start breaking up quite badly and sounding scratchy as soon as keys are pressed over a certain rate (not that fast). It recovers again if you slow down.
This happened on my previous Windows 10 PC (a Xeon 32.GHz HP Z400 workstation with 24GB RAM and SSDs and a Focusrite Scarlett 8i6 audio interface).
I was hoping that my recently-purchased PC upgrade would perform a lot better and solve this.
Iāve now got an HP Z2 workstation with i9-12900 CPU and 32GB RAM, the main SSD is an M.2 NVME. So you would this this spec should be enough!
However Iām still getting the same trouble. This could suggest its software problems because I imaged the old Windows 10 system over to the new PC. There might be a driver issue or something thatās come over.
Iāve tried tweaking the Focusrite ASIO settings all the way up to a 1024 buffer size and various other options. I have also tried using the ASIO to my Yamaha MODX D/A output and that does the same thing.
Following the advice in this thread, Iām currently running a LatencyMon test, which is reporting that the system is having trouble handling real-time audio. I reckons that DPC routines may be taking too long and the highest DPC count is coming from Microsoftās storport.sys (Storage Port Driver).
Does anyone have advice on what I can do next to try to fix/improve this?
Thanks,
Alex
Hi @AlexB,
regarding Serum, I have had a similar experience. I noticed that many presets had long release times, which combined with a large polyphony value implied that many notes were playing at the same time (even if some of them were already so low in volume to be hardly noticeable).
Making the release time shorter and decreasing the polyphony greatly reduced the problem.
Also look out for long reverb decay timesā¦they also need time to be calculated, adding up to the overall time load.
Gabriel
Hi Gabriel,
Thanks for your suggestions.
I did try increasing polyphony but didnāt gain much improvement.
It is true that it tends to be the evolving pads that suffer the most. So that could be due to release times and/or reverb decaysā¦
Iāll give them both a try later tonight.
Cheers,
Alex
I donāt know if you actually meant de-creasing, here butā¦by increasing the polyphony you just make things harder for the plugin. A low value means less notes to calculate and more chances to process the audio buffer in time for a new one (so that you get a time load lower than 100%).
Gabriel
.
Sorry, I wasnāt thinking right (just finished a long day at work!).
Yes, of course decreasing polyphony will reduce processing load.
However I just went to test and now I canāt break it
I was running LatencyMon for ages earlier and it was saying my system had issues, probably due to DPC latency.
I went to double-check power settings before trying anything else and realised I was in Balanced rather than High Power for some reason. I switched to High Power and restarted LatencyMon but it didnāt seem to make a lot of difference.
Then I ran DPClat.exe for a while but that seemed to show DPC was okay.
I did a bit more research about possible causes and someone on the sysnative forums suggested making sure Windows Driver Verifier was not monitoring drivers in realtime for rogue code.
I ran VERIFY /RESET from an admin command prompt but it returned that no changes were made (as no driver was in its verify list, I guess)
I then re-ran LatencyMon and it has remained running for an hour or so saying my system is fine. The storport.sys is way down the list of DPC hogs now.
So then I tried Serum x64 and other VSTs that were behaving terribly last night and they now appear to be clear of this breaking up.
So just to prove it was the power settings, I returned them to Balanced. No change however.
Then I put my ASIO buffer size down from 1024 to 256 (because I could hear a little delay). Still no change.
I must say Iām very happy but somewhat confused now to what has actually fixed this and just hope its permanent.
Just for the record and in case it helps anyone else, my PC has absolutely flown for the rest of this evening and the Serum VST has been working fantastically without any sound issues.
I can only put it down to having done that reset of the Windows Driver Verifier.
According to the list of drivers shown in the Verifier, none of them was enabled for monitoring & stressing. When I did the reset, it returned that āNo changes were madeā and I did not reboot afterwards either.
However something has dramatically changed and it feels like a lot of āstickinessā that I felt at times with the response from the SSDs has disappeared. Everything opens and saves very much faster.