Kristof St
Hi all
Are there VDJ (8.2 build 3848) users here that have experienced the following with Denon MCX8000:
For several months now I'm working with VDJ 8.2 and Denon MCX8000 Controller.
Often, after several hours working, the sound (headphone and master out (speakers)) starts containing cracks and clicks (comparable with scratches on a vinyl).
And the longer I continue, the worse it gets. Never had this issue when using Traktor Pro + MCX8000.
My latency is set to the standard value (Automatic: 512).
The ultraLatency is set to YES
Could this ultraLatency setting have anything to do with it ? It says to turn off ultraLatency when hearing cracks, but the first hours I hear no cracks. They start to occur after several hours. Is there a downside for turning ultraLatency OFF ? I rather ask before adjusting (experimenting).
Yesterday I had it again (after only playing for about 3 hours) at a wedding party. I took a risk and opened VDJ audio settings and pushed on 'Apply' so the audio driver was 'reactivated'. After that the cracks and clicks were gone.
It seems like the audio driver is becoming unstable after a while working with VDJ.
Question is: is this a VDJ or Denon MCX 8000 (driver) issue ?
Anybody using MCX8000 and VDJ experienced this issue ?
It worries me and makes me insecure about the stability and reliability (which is a hell when playing for many hours all-night-sets)
Using HP Pro from 2017 (DJ dedicated, only for DJing, no other software), Win10, no internet, no wifi, no anti-virus
Are there VDJ (8.2 build 3848) users here that have experienced the following with Denon MCX8000:
For several months now I'm working with VDJ 8.2 and Denon MCX8000 Controller.
Often, after several hours working, the sound (headphone and master out (speakers)) starts containing cracks and clicks (comparable with scratches on a vinyl).
And the longer I continue, the worse it gets. Never had this issue when using Traktor Pro + MCX8000.
My latency is set to the standard value (Automatic: 512).
The ultraLatency is set to YES
Could this ultraLatency setting have anything to do with it ? It says to turn off ultraLatency when hearing cracks, but the first hours I hear no cracks. They start to occur after several hours. Is there a downside for turning ultraLatency OFF ? I rather ask before adjusting (experimenting).
Yesterday I had it again (after only playing for about 3 hours) at a wedding party. I took a risk and opened VDJ audio settings and pushed on 'Apply' so the audio driver was 'reactivated'. After that the cracks and clicks were gone.
It seems like the audio driver is becoming unstable after a while working with VDJ.
Question is: is this a VDJ or Denon MCX 8000 (driver) issue ?
Anybody using MCX8000 and VDJ experienced this issue ?
It worries me and makes me insecure about the stability and reliability (which is a hell when playing for many hours all-night-sets)
Using HP Pro from 2017 (DJ dedicated, only for DJing, no other software), Win10, no internet, no wifi, no anti-virus
发表时间 Sun 08 Apr 18 @ 8:28 pm
wickedmix
is there some reason you are running that old build?
i would say update to latest release version and see if that clears it up.
i would say update to latest release version and see if that clears it up.
发表时间 Sun 08 Apr 18 @ 9:14 pm
klausmogensen
It may be a buffer issue withthe driver
If possible next time it happens, go into settings-> audio and simply click apply
That gives you a split sec of dead air, but then normally cleans up the driver buffer, which may fix the issue for the next few hours
If possible next time it happens, go into settings-> audio and simply click apply
That gives you a split sec of dead air, but then normally cleans up the driver buffer, which may fix the issue for the next few hours
发表时间 Sun 08 Apr 18 @ 9:57 pm
Kristof St
@wickedmix:
I'm not a big fan of updating software that works fine for me as it is. If it's not broken, no need to fix it. Besides this issue, which I'm trying to figure out if it is a VDJ issue or a driver (Denon) issue, I have no issues with the build I'm suing. (I follow (check regularly) the changelog (standard log and early access) to see what has been fixed and/or added. If I find nothing interesting to my concern, I don't upgrade.)
That's why I put my issue on the forum first. Maybe someone has had this issue in the past and maybe could point out that the problem was fixed after a certain update (higher build version). Because I am aware of the fact that things can be fixed 'under the hood' and are not always listed in the changelog with a new build. If this issue should still occur with the latest build, no need in updating to the last build because it wouldn't solve my problem :-) (besides this issue, I have no other issue's).
But if no MCX8000 user has this issue with the latest build version, I will update to the latest build. That would be a good reason to update :-)
@klausmogensen:
That's what I did (click apply) and the clicks stopped. But I'm trying to figure out how to prevent it from happening instead of solving it when happening :-)
If no one has experienced this specific issue, I will set ultraLatency OFF and see if this solves anything.
Thanks for your reply's !
I'm not a big fan of updating software that works fine for me as it is. If it's not broken, no need to fix it. Besides this issue, which I'm trying to figure out if it is a VDJ issue or a driver (Denon) issue, I have no issues with the build I'm suing. (I follow (check regularly) the changelog (standard log and early access) to see what has been fixed and/or added. If I find nothing interesting to my concern, I don't upgrade.)
That's why I put my issue on the forum first. Maybe someone has had this issue in the past and maybe could point out that the problem was fixed after a certain update (higher build version). Because I am aware of the fact that things can be fixed 'under the hood' and are not always listed in the changelog with a new build. If this issue should still occur with the latest build, no need in updating to the last build because it wouldn't solve my problem :-) (besides this issue, I have no other issue's).
But if no MCX8000 user has this issue with the latest build version, I will update to the latest build. That would be a good reason to update :-)
@klausmogensen:
That's what I did (click apply) and the clicks stopped. But I'm trying to figure out how to prevent it from happening instead of solving it when happening :-)
If no one has experienced this specific issue, I will set ultraLatency OFF and see if this solves anything.
Thanks for your reply's !
发表时间 Sun 08 Apr 18 @ 11:32 pm
Kristof St
Seems ultraLatency was already OFF on my DJ dedicated laptop (on which the audio-cracks-issue occurred Saturday), so that's not the solution.
I ran LatencyMon just now and Wdf01000.sys seems to be spiking, although for the moment there are no clicks in the sound (system is playing in Automix mode for 3 hours now).
But it worries me the Wdf01000.sys seems to be causing spikes. Not 'healthy' for good audio performance I guess. And maybe also causing the sound cracks after a while.
Any suggestions what I should do to reduce these spikes to a normal level ? I checked power management, all seems optimal.
I'm not an IT specialist/programmer, so not sure how to handle/solve this problem.
Suggestions or help much appreciated :-)
This is the Conclusion-report from the LatencyMon:
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. Also one or more ISR 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 0:21:08 (h:mm:ss) on all processors.
_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name: DJ
OS version: Windows 10 , 10.0, build: 15063 (x64)
Hardware: HP Laptop 17-bs0xx, HP, 8339
CPU: GenuineIntel Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
Logical processors: 4
Processor groups: 1
RAM: 8064 MB total
_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed: 2712 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.
_________________________________________________________________________________________________________
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): 2775,974829
Average measured interrupt to process latency (µs): 8,789534
Highest measured interrupt to DPC latency (µs): 2772,576601
Average measured interrupt to DPC latency (µs): 3,666141
_________________________________________________________________________________________________________
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): 2488,815265
Driver with highest ISR routine execution time: Wdf01000.sys - Kernel Mode Driver Framework-runtime, Microsoft Corporation
Highest reported total ISR routine time (%): 0,091006
Driver with highest ISR total time: Wdf01000.sys - Kernel Mode Driver Framework-runtime, Microsoft Corporation
Total time spent in ISRs (%) 0,092175
ISR count (execution time <250 µs): 3685400
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): 7
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): 2942,995575
Driver with highest DPC routine execution time: Wdf01000.sys - Kernel Mode Driver Framework-runtime, Microsoft Corporation
Highest reported total DPC routine time (%): 2,089291
Driver with highest DPC total execution time: Wdf01000.sys - Kernel Mode Driver Framework-runtime, Microsoft Corporation
Total time spent in DPCs (%) 2,547275
DPC count (execution time <250 µs): 9334758
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-999 µs): 3933
DPC count (execution time 1000-1999 µs): 23
DPC count (execution time 2000-3999 µs): 855
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.
Process with highest pagefault count: none
Total number of hard pagefaults 0
Hard pagefault count of hardest hit process: 0
Highest hard pagefault resolution time (µs): 0,0
Total time spent in hard pagefaults (%): 0,0
Number of processes hit: 0
_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s): 129,132380
CPU 0 ISR highest execution time (µs): 2484,067847
CPU 0 ISR total execution time (s): 2,461698
CPU 0 ISR count: 1961472
CPU 0 DPC highest execution time (µs): 2942,995575
CPU 0 DPC total execution time (s): 115,534948
CPU 0 DPC count: 6857113
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s): 44,353808
CPU 1 ISR highest execution time (µs): 2488,815265
CPU 1 ISR total execution time (s): 1,857372
CPU 1 ISR count: 1308058
CPU 1 DPC highest execution time (µs): 2448,988938
CPU 1 DPC total execution time (s): 3,821001
CPU 1 DPC count: 495945
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s): 20,616722
CPU 2 ISR highest execution time (µs): 2423,833333
CPU 2 ISR total execution time (s): 0,165866
CPU 2 ISR count: 182749
CPU 2 DPC highest execution time (µs): 643,845870
CPU 2 DPC total execution time (s): 7,532864
CPU 2 DPC count: 1534697
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s): 35,423832
CPU 3 ISR highest execution time (µs): 2483,823746
CPU 3 ISR total execution time (s): 0,190245
CPU 3 ISR count: 233128
CPU 3 DPC highest execution time (µs): 570,226770
CPU 3 DPC total execution time (s): 2,310584
CPU 3 DPC count: 451814
I ran LatencyMon just now and Wdf01000.sys seems to be spiking, although for the moment there are no clicks in the sound (system is playing in Automix mode for 3 hours now).
But it worries me the Wdf01000.sys seems to be causing spikes. Not 'healthy' for good audio performance I guess. And maybe also causing the sound cracks after a while.
Any suggestions what I should do to reduce these spikes to a normal level ? I checked power management, all seems optimal.
I'm not an IT specialist/programmer, so not sure how to handle/solve this problem.
Suggestions or help much appreciated :-)
This is the Conclusion-report from the LatencyMon:
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. Also one or more ISR 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 0:21:08 (h:mm:ss) on all processors.
_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name: DJ
OS version: Windows 10 , 10.0, build: 15063 (x64)
Hardware: HP Laptop 17-bs0xx, HP, 8339
CPU: GenuineIntel Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
Logical processors: 4
Processor groups: 1
RAM: 8064 MB total
_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed: 2712 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.
_________________________________________________________________________________________________________
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): 2775,974829
Average measured interrupt to process latency (µs): 8,789534
Highest measured interrupt to DPC latency (µs): 2772,576601
Average measured interrupt to DPC latency (µs): 3,666141
_________________________________________________________________________________________________________
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): 2488,815265
Driver with highest ISR routine execution time: Wdf01000.sys - Kernel Mode Driver Framework-runtime, Microsoft Corporation
Highest reported total ISR routine time (%): 0,091006
Driver with highest ISR total time: Wdf01000.sys - Kernel Mode Driver Framework-runtime, Microsoft Corporation
Total time spent in ISRs (%) 0,092175
ISR count (execution time <250 µs): 3685400
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): 7
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): 2942,995575
Driver with highest DPC routine execution time: Wdf01000.sys - Kernel Mode Driver Framework-runtime, Microsoft Corporation
Highest reported total DPC routine time (%): 2,089291
Driver with highest DPC total execution time: Wdf01000.sys - Kernel Mode Driver Framework-runtime, Microsoft Corporation
Total time spent in DPCs (%) 2,547275
DPC count (execution time <250 µs): 9334758
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-999 µs): 3933
DPC count (execution time 1000-1999 µs): 23
DPC count (execution time 2000-3999 µs): 855
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.
Process with highest pagefault count: none
Total number of hard pagefaults 0
Hard pagefault count of hardest hit process: 0
Highest hard pagefault resolution time (µs): 0,0
Total time spent in hard pagefaults (%): 0,0
Number of processes hit: 0
_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s): 129,132380
CPU 0 ISR highest execution time (µs): 2484,067847
CPU 0 ISR total execution time (s): 2,461698
CPU 0 ISR count: 1961472
CPU 0 DPC highest execution time (µs): 2942,995575
CPU 0 DPC total execution time (s): 115,534948
CPU 0 DPC count: 6857113
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s): 44,353808
CPU 1 ISR highest execution time (µs): 2488,815265
CPU 1 ISR total execution time (s): 1,857372
CPU 1 ISR count: 1308058
CPU 1 DPC highest execution time (µs): 2448,988938
CPU 1 DPC total execution time (s): 3,821001
CPU 1 DPC count: 495945
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s): 20,616722
CPU 2 ISR highest execution time (µs): 2423,833333
CPU 2 ISR total execution time (s): 0,165866
CPU 2 ISR count: 182749
CPU 2 DPC highest execution time (µs): 643,845870
CPU 2 DPC total execution time (s): 7,532864
CPU 2 DPC count: 1534697
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s): 35,423832
CPU 3 ISR highest execution time (µs): 2483,823746
CPU 3 ISR total execution time (s): 0,190245
CPU 3 ISR count: 233128
CPU 3 DPC highest execution time (µs): 570,226770
CPU 3 DPC total execution time (s): 2,310584
CPU 3 DPC count: 451814
发表时间 Mon 09 Apr 18 @ 10:18 pm
Adion
Highest measured is still only 3 ms, so if you set the latency at 10ms that should still leave enough time for processing
发表时间 Tue 10 Apr 18 @ 2:33 am
kmellish
Kristof, i am having the same issue as you. What is your fix to the static crack sound?? Please let me know ... a lot of people have this issue but there is nobody that tells us how to fix the crack static sound. It may be 1 hour into a job, it may be 3 hours into a job. its unknown. i went 6 months with no issues then it started again.
发表时间 Sat 25 Jan 20 @ 7:53 pm
kradcliffe
PC latency. Simple as that. No easy fix as it needs investigating.
发表时间 Sat 25 Jan 20 @ 8:14 pm
wickedmix
kmellish wrote :
Kristof, i am having the same issue as you. What is your fix to the static crack sound?? Please let me know ... a lot of people have this issue but there is nobody that tells us how to fix the crack static sound. It may be 1 hour into a job, it may be 3 hours into a job. its unknown. i went 6 months with no issues then it started again.
i am telling you the answer
your latency is set to low
set it higher
reference this -> https://www.virtualdj.com/wiki/Sound%20Issues.html
发表时间 Sat 25 Jan 20 @ 8:14 pm
Mobile Zombie
This is a long shot. But I had very similair problems with a certain PC resulting exactly this behaviour with my MCX8000.
The problem in my case was my USB3 ports, they seemed to not being able to cope with high continous dataflow.
In BIOS I changed settings for USB3 ports to behave like USB2 ports and after this, no disturbance or other weird things ever happened.
As a side note, this PC had extremely low DPC latency.
The problem in my case was my USB3 ports, they seemed to not being able to cope with high continous dataflow.
In BIOS I changed settings for USB3 ports to behave like USB2 ports and after this, no disturbance or other weird things ever happened.
As a side note, this PC had extremely low DPC latency.
发表时间 Mon 27 Jan 20 @ 9:55 am