Staring to have problems again. Frequent audio dropouts. And now this:
Recording Error: Too many tracks recording.
Does anybody know what this might mean?
(clue: it does NOT mean there are too many tracks recording. It happens, as often as not, when a single track is recording)
Hi,
Please, test your system via LatencyMon to know, where is the bottleneck of your audio stream is.
Also make sure, you have enough free space on your HDD, please.
thanks, I’ll try LatencyMon and see what it tells me.
I have 600GB free on my system drive (where Cubase resides), and 280GB free on the drive containing my project files.
I suspect there’s a plugin causing the problem. It happened repeatedly the day I posted this, but hasn’t happened since.
Also, Martin, for some reason I never got a notification of your reply. Sorry it took so long to acknowledge it…
This problem went away for awhile, but has suddenly come back.
I’ve discovered Steinberg has a support article here, but it’s no help. I says the problem is known to occur sometimes if you have an NVidia graphics card installed (I don’t) and are recording a few tracks at once (I’m not, this typically happens when I’m only recording one track).
It would be nice if software engineers would put meaningful messages in their error screens. (I’d say a message that says “too many tracks recording” when the error obviously has nothing to do with the number of tracks you’re recording qualifies as a “bug”.)
The random audio drop-outs (which never quite went away, but became rare enough to not be much of a problem) have also returned…
I ran LatencyMon for about a half hour, and it said
Your system appears to be suitable for handling real-time audio and other tasks without dropouts.
(The display did, however indicate “hard pagefaults” in the red). I neglected to get a screenshot at that time, but here’s a similar one I just took after running about 10 minutes:
So I left LatencyMon running overnight. In the morning the results were quite different:
Your system appears to be having trouble handling real-time audio and other tasks. You are likely to experience buffer underruns appearing as drop outs, clicks or pops. One or more DPC routines that belong to a driver running in your system appear to be executing for too long. One problem may be related to power management, disable CPU throttling settings in Control Panel and BIOS setup. Check for BIOS updates. LatencyMon has been analyzing your system for 19:12:58 (h:mm:ss) on all processors.
I turned off all power management features a long time ago, but it made no difference.
I’m having trouble interpreting the results. Can anyone here help me?
CONCLUSION
Your system appears to be having trouble handling real-time audio and other tasks. You are likely to experience buffer underruns appearing as drop outs, clicks or pops. One or more DPC routines that belong to a driver running in your system appear to be executing for too long. One problem may be related to power management, disable CPU throttling settings in Control Panel and BIOS setup. Check for BIOS updates. LatencyMon has been analyzing your system for 19:12:58 (h:mm:ss) on all processors.
\
SYSTEM INFORMATION
Computer name: DRYCREEKDAW
OS version: Windows 7 Service Pack 1, 6.1, build: 7601 (x64)
Hardware: Z68A-D3H-B3, Gigabyte Technology Co., Ltd.
CPU: GenuineIntel Intel(R) Core™ i5-2400 CPU @ 3.10GHz
Logical processors: 4
Processor groups: 1
RAM: 16301 MB total
\
CPU SPEED
Reported CPU speed: 3109 MHz
Measured CPU speed: 1 MHz (approx.)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): 6338.350329
Average measured interrupt to process latency (µs): 3.988367Highest measured interrupt to DPC latency (µs): 781.548731
Average measured interrupt to DPC latency (µs): 0.821114
\
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): 135.663557
Driver with highest ISR routine execution time: ACPI.sys - ACPI Driver for NT, Microsoft CorporationHighest reported total ISR routine time (%): 0.124838
Driver with highest ISR total time: hal.dll - Hardware Abstraction Layer DLL, MicrosoftCorporation
Total time spent in ISRs (%) 0.128669
ISR count (execution time <250 µs): 72786378
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): 1557.360888
Driver with highest DPC routine execution time: storport.sys - Microsoft Storage Port Driver, Microsoft CorporationHighest reported total DPC routine time (%): 0.054476
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.112580
DPC count (execution time <250 µs): 215787681
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-999 µs): 13
DPC count (execution time 1000-1999 µs): 2
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: msmpeng.exe
Total number of hard pagefaults 156794
Hard pagefault count of hardest hit process: 92986
Highest hard pagefault resolution time (µs): 7470285.403667
Total time spent in hard pagefaults (%): 0.075598
Number of processes hit: 21
\
PER CPU DATA
CPU 0 Interrupt cycle time (s): 1313.558937
CPU 0 ISR highest execution time (µs): 135.663557
CPU 0 ISR total execution time (s): 356.043880
CPU 0 ISR count: 72786378
CPU 0 DPC highest execution time (µs): 1557.360888
CPU 0 DPC total execution time (s): 288.244747
CPU 0 DPC count: 206681711
CPU 1 Interrupt cycle time (s): 207.017672
CPU 1 ISR highest execution time (µs): 0.0
CPU 1 ISR total execution time (s): 0.0
CPU 1 ISR count: 0
CPU 1 DPC highest execution time (µs): 212.599871
CPU 1 DPC total execution time (s): 3.309396
CPU 1 DPC count: 1143216
CPU 2 Interrupt cycle time (s): 2247.746407
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): 179.325507
CPU 2 DPC total execution time (s): 9.259974
CPU 2 DPC count: 3407636
CPU 3 Interrupt cycle time (s): 902.550271
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): 227.354455
CPU 3 DPC total execution time (s): 10.708577
CPU 3 DPC count: 4555133
Your interface is classified as “Legacy” by M-Audio, and the card interface does look archaic. According to their website, the latest driver (Delta 6.0.8) was last updated in March of 2012. This would lead me to believe that the driver is “behind the times” in one sense or another. Possibly there’s new hardware that’s incompatible, or the BIOS is too new for it, or the OS has been changed/updated.
My bet would be that a Microsoft update is to blame. It’s unlikely that you flashed the BIOS recently, and any new hardware would be accessed thru the OS or BIOS. I also noticed that your report indicates that msmpeng.exe had the largest number of page faults. It amazes me that the OS is using virtual memory when you have 16 GB or RAM. msmpeng.exe is associated with Windows Defender. So if I were you, I’d start there. When I google msmpeng.exe, I see that high CPU usage is a serious compliant, and that many of these complaints are old. Some solutions also seem to be posted and maybe that would work. A cheap solution might be to suspend Windows Defender when running Cubase. You could protect your DAW by disconnecting from the internet during Cubase usage. (unless the dongle needs internet access – an issue I’m not clear on – but in that case you could pull the internet connection after Cubase loads.) After Cubase usage, you could restart Windows Defender and reconnect.
Now that might not be the only problem, but you could disable Windows Defender and rerun LatencyMon to see what pops up next (if anything). Would going to Windows 10 solve the problem? (Perhaps it wouldn’t be using virtual memory so much.) I do not know. It’s probably not an option, since your interface has no driver support for Windows 10.
You have my sympathies. Good luck.
Pretty sure I tried turning off Windows Defender once before, and it made no difference, but I didn’t have LatencyMon then. I’ll try again and post findings.
It might be that it’s active because it’s fighting a virus/malware. Maybe you should disinfect your computer before doing this. Interesting to look at what people are saying about this issue (I get these off the first page of Google):
https://www.sevenforums.com/system-security/280493-msmpeng-exe-taking-up-too-much-memory.html
… and I’m sure there’s much more. You might want to start with the safer options first, testing after each “solution”, and stop applying solutions as soon as you succeed. For example:
Thanks, I do thorough malware scans pretty regularly (using Microsoft Security Essentials, Malwarebytes, and AdwCleaner).
The only one running in realtime is Microsoft Security Essentials (MSMpEng.exe). I’ve already tried all these suggestions. Excluding directories causing it to “fight itself” did result in better bootup times. And while it is a still a bit of a resource hog, turning it off made no difference in Cubase performance (nor did it seem to affect LatencyMon results significantly).
I’m convinced the problem is really that I’m trying to hold onto legacy gear in a software environment evolving beyond compatibility. (In other words - Microsoft has no respect for legacy components, and with each upgrade they, perhaps intentionally, push them closer to obsolescence, no matter how good they are).
I had this problem today and solved it by opening the program as administrator 
