Jump to content
JoeGBradford

Stuttering after loading several patches in various synths

Recommended Posts

Hi all

This is an issue I first encountered when using the new presets I bought for Union synth but is now also happening in Zampler that I have just got some free presets for via Beat magazine.

After auditioning several patches I get a stuttering in CbB - close down CbB and open up again all is fine until I have scrolled through a few more patches then the stuttering starts. I've checked buffer size and processor load and all is fine there - as I say it only happens with some synths - it has occurred with Sampletank 3 previously but ST 4 has been fine. 

I'm on latest versions of CbB and Win 10. Using Thread Scheduling Config 2 i5 quad core CPU and 8 Gb of RAM. VST's are on an external SSD connected via USB 3.1. Using ASIO 4 All with onboard sound card (which has been fine for years though I know some people don't like it!) 

Any ideas? It's a bit frustrating having to close CbB down every few minutes when I use these synths! There maybe others with the problem but most I use have been absoultely fine

Share this post


Link to post
Share on other sites

It may be a memory issue. Union recommends a minimum 8GB. IIRC, Zampler and Sampletank load all of the samples needed for a preset into memory, Consider going to 16GB or more if using a lot of sample-based instruments.

 

Share this post


Link to post
Share on other sites

Thanks. I was wondering if it might be memory as it only happens after I have loaded several patches. Would the loading of several patches in short succession potentially overload the RAM

Share this post


Link to post
Share on other sites
16 minutes ago, JoeGBradford said:

Would the loading of several patches in short succession potentially overload the RAM

Doubt that matters. Should be able to see what is going on with memory in the Windows task manager. Unfortunately, Windows can only report CbB as a whole and not what plug-ins are doing inside the program.

 

Share this post


Link to post
Share on other sites

You could run LatencyMon to see if you are getting excessive page faults. Windows might be swapping memory in and out to the page file on disk in an "unfriendly to audio samples" manner.

Also you can open Resource Monitor from Task Manager by clicking the link at the bottom of the Performance tab. Then look at the Disk tab. It will show the open files being used. You can sort views there by clicking on the column headings. For example I can see all processes that are actively using "C:\Pagefile.Sys".

As scook mentioned though, CbB will be reported as a whole, not by individual plugins.

I have also never tried to run samples from an external drive. YMMV. That performance might differ by the plugin design, and how often the samples are read by the plugin, i.e., sample streaming.

Bottom line for the page file issue is that more RAM reduces the need for page file usage. I  suppose some folks may even disable it if they have massive amounts of extra RAM (through Control Panel > System > Advanced system settings > Advanced > Performance  >  Settings > Advanced > Virtual memory).

Edited by abacab
  • Thanks 1

Share this post


Link to post
Share on other sites

Thanks - I ran Latency Mon whilst playing different patches with Zampler and this was the result - apart from first couple of sections I am afraid I do not know what any of it means so would appreciate advice. I seem to remember when I tried task manager I couldn't look at it whilst in CbB but will try it again

 

CONCLUSION
_________________________________________________________________________________________________________
Your system appears to be suitable for handling real-time audio and other tasks without dropouts. 
LatencyMon has been analyzing your system for  0:03:28  (h:mm:ss) on all processors.


_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name:                                        JOE-PC
OS version:                                           Windows 10 , 10.0, build: 18363 (x64)
Hardware:                                             ASUSTeK Computer INC., P8Z68-V LE
CPU:                                                  GenuineIntel Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz
Logical processors:                                   4
Processor groups:                                     1
RAM:                                                  8172 MB total


_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed:                                   3311 MHz

Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.

WARNING: the CPU speed that was measured is only a fraction of the CPU speed reported. Your CPUs may be throttled back due to variable speed settings and thermal issues. It is suggested that you run a utility which reports your actual CPU frequency and temperature. 

_________________________________________________________________________________________________________
MEASURED INTERRUPT TO USER PROCESS LATENCIES
_________________________________________________________________________________________________________
The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.

Highest measured interrupt to process latency (µs):   319.60
Average measured interrupt to process latency (µs):   5.353070

Highest measured interrupt to DPC latency (µs):       313.30
Average measured interrupt to DPC latency (µs):       1.594756


_________________________________________________________________________________________________________
 REPORTED ISRs
_________________________________________________________________________________________________________
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.

Highest ISR routine execution time (µs):              155.443371
Driver with highest ISR routine execution time:       dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation

Highest reported total ISR routine time (%):          0.093462
Driver with highest ISR total time:                   dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation

Total time spent in ISRs (%)                          0.102324

ISR count (execution time <250 µs):                   43400
ISR count (execution time 250-500 µs):                0
ISR count (execution time 500-999 µs):                0
ISR count (execution time 1000-1999 µs):              0
ISR count (execution time 2000-3999 µs):              0
ISR count (execution time >=4000 µs):                 0


_________________________________________________________________________________________________________
REPORTED DPCs
_________________________________________________________________________________________________________
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.

Highest DPC routine execution time (µs):              619.970704
Driver with highest DPC routine execution time:       ntoskrnl.exe - NT Kernel & System, Microsoft Corporation

Highest reported total DPC routine time (%):          0.058823
Driver with highest DPC total execution time:         rspLLL64.sys - Resplendence Latency Monitoring and Auxiliary Kernel Library, Resplendence Software Projects Sp.

Total time spent in DPCs (%)                          0.234657

DPC count (execution time <250 µs):                   564512
DPC count (execution time 250-500 µs):                0
DPC count (execution time 500-999 µs):                3
DPC count (execution time 1000-1999 µs):              0
DPC count (execution time 2000-3999 µs):              0
DPC count (execution time >=4000 µs):                 0


_________________________________________________________________________________________________________
 REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.

NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.

Process with highest pagefault count:                 dropbox.exe

Total number of hard pagefaults                       3060
Hard pagefault count of hardest hit process:          2644
Number of processes hit:                              29


_________________________________________________________________________________________________________
 PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s):                       7.942864
CPU 0 ISR highest execution time (µs):                155.443371
CPU 0 ISR total execution time (s):                   0.850463
CPU 0 ISR count:                                      43301
CPU 0 DPC highest execution time (µs):                310.951072
CPU 0 DPC total execution time (s):                   1.614055
CPU 0 DPC count:                                      425836
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s):                       4.920021
CPU 1 ISR highest execution time (µs):                59.606463
CPU 1 ISR total execution time (s):                   0.000941
CPU 1 ISR count:                                      99
CPU 1 DPC highest execution time (µs):                203.456660
CPU 1 DPC total execution time (s):                   0.024941
CPU 1 DPC count:                                      3152
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s):                       7.101523
CPU 2 ISR highest execution time (µs):                0.0
CPU 2 ISR total execution time (s):                   0.0
CPU 2 ISR count:                                      0
CPU 2 DPC highest execution time (µs):                619.970704
CPU 2 DPC total execution time (s):                   0.292943
CPU 2 DPC count:                                      133004
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s):                       3.623097
CPU 3 ISR highest execution time (µs):                0.0
CPU 3 ISR total execution time (s):                   0.0
CPU 3 ISR count:                                      0
CPU 3 DPC highest execution time (µs):                121.637874
CPU 3 DPC total execution time (s):                   0.020560
CPU 3 DPC count:                                      2523
_________________________________________________________________________________________________________
 

Share this post


Link to post
Share on other sites

Managed to inspect Task Manager whilst running CbB with Zampler and changing patches to the point that it stuttered - non of the figures varied much from this

 

image.thumb.png.0723373b29e31ccf47e728baf4d212b3.png

Share this post


Link to post
Share on other sites

I was though getting 14 late buffers when I hovered over the performance bar. However, and this is the first time I have noticed this, I didn't play anything whilst I was typing the above message and the stuttering has gone!

Hopefully the above will give a clue as to what my problem is!

Share this post


Link to post
Share on other sites

Are you changing presets while the transport is running?

 

Share this post


Link to post
Share on other sites

Ah sorry - another revelation - if I go to chrome when I have had the stuttering and then back to CbB immediately stuttering stops!

Share this post


Link to post
Share on other sites

The images indicate there is plenty of memory.

What are your ASIO buffer settings? Have you tried adjusting them"

Have you tried WASAPI driver mode?

 

Share this post


Link to post
Share on other sites

Thanks

ASIO 4 All is set at 2048 samples - the maximum available - it was the first thing I checked

I did try WASAPI once but couldn't get it to work - presumably some incorrect settings - perhaps I need to try again

Share this post


Link to post
Share on other sites

Have you tried lowering the buffer size? Sometimes extreme settings high or low can be a problem.

 

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