JoeGBradford Posted June 8, 2020 Share Posted June 8, 2020 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 Link to comment Share on other sites More sharing options...
scook Posted June 8, 2020 Share Posted June 8, 2020 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. Link to comment Share on other sites More sharing options...
JoeGBradford Posted June 8, 2020 Author Share Posted June 8, 2020 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 Link to comment Share on other sites More sharing options...
scook Posted June 8, 2020 Share Posted June 8, 2020 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. Link to comment Share on other sites More sharing options...
JoeGBradford Posted June 8, 2020 Author Share Posted June 8, 2020 Thanks I'll check that out. Actually I may have already looked at that when it first happened but not sure Link to comment Share on other sites More sharing options...
abacab Posted June 9, 2020 Share Posted June 9, 2020 (edited) 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 June 9, 2020 by abacab 1 Link to comment Share on other sites More sharing options...
JoeGBradford Posted June 9, 2020 Author Share Posted June 9, 2020 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 _________________________________________________________________________________________________________ Link to comment Share on other sites More sharing options...
JoeGBradford Posted June 9, 2020 Author Share Posted June 9, 2020 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 Link to comment Share on other sites More sharing options...
JoeGBradford Posted June 9, 2020 Author Share Posted June 9, 2020 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! Link to comment Share on other sites More sharing options...
scook Posted June 9, 2020 Share Posted June 9, 2020 Are you changing presets while the transport is running? Link to comment Share on other sites More sharing options...
JoeGBradford Posted June 9, 2020 Author Share Posted June 9, 2020 Ah sorry - another revelation - if I go to chrome when I have had the stuttering and then back to CbB immediately stuttering stops! Link to comment Share on other sites More sharing options...
JoeGBradford Posted June 9, 2020 Author Share Posted June 9, 2020 2 minutes ago, scook said: Are you changing presets while the transport is running? Yes Link to comment Share on other sites More sharing options...
JoeGBradford Posted June 9, 2020 Author Share Posted June 9, 2020 Which probably relates to my last comment? Link to comment Share on other sites More sharing options...
JoeGBradford Posted June 9, 2020 Author Share Posted June 9, 2020 Sorry my answer to that should have been no - the audio engine is running but not the transport ! Link to comment Share on other sites More sharing options...
scook Posted June 9, 2020 Share Posted June 9, 2020 OK, the engine running is not the same as the transport. Link to comment Share on other sites More sharing options...
JoeGBradford Posted June 9, 2020 Author Share Posted June 9, 2020 Yeah I know - sorry! Brain fade! Link to comment Share on other sites More sharing options...
scook Posted June 10, 2020 Share Posted June 10, 2020 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? Link to comment Share on other sites More sharing options...
JoeGBradford Posted June 10, 2020 Author Share Posted June 10, 2020 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 Link to comment Share on other sites More sharing options...
scook Posted June 10, 2020 Share Posted June 10, 2020 Have you tried lowering the buffer size? Sometimes extreme settings high or low can be a problem. Link to comment Share on other sites More sharing options...
JoeGBradford Posted June 10, 2020 Author Share Posted June 10, 2020 Thanks I'll try that tomorrow Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now