Entra:     

Forum: VirtualDJ Technical Support

Topic: Audio glitching when using motorized platters (build 9336) - Page: 1
Hey everyone!

I'm encountering a strange issue when using Virtual DJ build 9336 with SC6000M players.

When the engine isn't enabled, everything works perfectly. But when I enable the engine, there are random audio glitches that cause the mix to become out of sync during transitions between tracks.

I'm experiencing the same issue at home with my laptop and my two personal SC6000M players, and the phenomenon also occurs at the club's setup (2 SC6000M players + an X1850 mixer).

Take any track, load it onto a deck, and play it with the engine active; you'll get a sort of audio glitch at some point that causes a kind of skip in the track. I should mention that I have quantize enabled on the players' screens most of the time; I haven't tried disabling quantize yet. I'm therefore forced to disable the player engines for the time being.

I haven't used the SC6000M with Virtual DJ for a while, so it's possible this problem already existed in previous builds. If it's a known bug, which build can I use while waiting for it to be fixed?

Here are the specs of both computers:

My personal laptop:

Windows 11 25h2 with the latest updates
i5-12450h
16 GB RAM
RTX 4060 8 GB
Phison 512 GB SSD + Patriot VP4300 2 TB SSD

Club computer (Desktop):
Ryzen 7 5800X
32 GB DDR4 3200 MHz RAM
MSI GTX 1080 Gaming X 8 GB
 
Inviato Wed 17 Jun 26 @ 8:12 pm
i get the exact issue with the SC6000 m
When the platters are spinning the sound glitch and the track goes out of sync
and when i turn them off the players are playing great
 
I explained the problem to Gemini, and here's their response:

This is a known issue on the VirtualDJ and Engine DJ forums, and it's become more noticeable in recent VirtualDJ builds (especially from version 2026 / build 9245 and above).

The root cause of the problem: The culprit isn't the physics engine itself, but rather the saturation of the USB bandwidth combined with the display processing.

When the engine is active, the SC6000M player sends a continuous and massive stream of high-precision MIDI/HID data to track the platter's rotation.

Simultaneously, VirtualDJ sends the large data back to the player to display the waveforms in real time on the SC6000M's large screens.

After a certain amount of time, a slight lag develops between the visuals and the audio. When VirtualDJ tries to "catch up" with this sudden delay, it causes this audio glitch and throws the mix off-sync.

The "Windows MIDI 2.0" Conflict (The Main Cause)
Microsoft rolled out a major update to its audio architecture, natively integrating the MIDI 2.0 protocol (via Windows 11 updates).

This new Windows service directly conflicts with the drivers of certain controllers (particularly those from InMusic, the owner of Denon DJ). This conflict overloads the processor and causes audio stuttering and controller freezes.

To fix this urgently, VirtualDJ integrated an option called disableMidi2 starting with build 9245 (located in the advanced settings or the missing controllers tab) to force the software to ignore the Windows MIDI 2.0 protocol.

Consequence: If you're using a recent build without having enabled this option (or if you're using an intermediate build), your SC6000M's MIDI engine will completely saturate the Windows MIDI stream.

Can someone from the development team confirm that this is indeed a problem related to the deployment of MIDI 2.0 in Windows 11?
 
That sounds all pretty made up
 
I don't know if Gemini's answer is made up or not; I'm just posting his response to look for a solution to this problem, which I'm clearly not alone in experiencing.

But I think he's probably not too far off the mark regarding MIDI 2.0, because this audio glitch does indeed cause a random jump (I don't know if it's forward or backward) in the track during playback, which causes the beatmatch to become desynchronized when the engines are active.

Whether DisableMIDI2 is enabled or not in VDJ makes no difference, even after restarting.

So I installed Windows MIDI Services, which I got from the following link, and it seems to have slightly improved the situation, as the audio glitches are now more occasional.

https://microsoft.github.io/MIDI/get-latest/


Before, I had two or three glitches every time I played a track, and now I get them on average once, but it's still unusable.

Activating the shortcut buttons on the players' screens to reduce the waveform height doesn't change anything, nor does limiting the framerate to 45 fps in VDJ's options.

Therefore, I would say that VDJ's explanation regarding the influx of MIDI data from the rotating platter in one direction and the influx of data arriving at the screens in the other direction, potentially causing USB bandwidth saturation, seems like a plausible explanation.

If anyone knows a simple method to disable MIDI 2.0 via Windows MIDI Services or a third-party tool that currently works, at least as a temporary solution so I can continue my tests while waiting for a fix, it would be a great help.
 
ill give the tool u shared a try. hope it fixes the issue for now till VDJ, Windows, and InMusic find a solution
 
This tool doesn't fix the problem; it just seems to make it less frequent since its installation, but it's still not a viable solution for using motorized platforms reliably.

@ADION
Could someone from the VDJ development team run some tests to see if the problem also occurs on your end and post feedback?
 
I have a Rane 4 and I am getting something that may be similar on my system as well. And it has moving platters. I load a song onto a deck and play it. And it will play fine for a while and then all of a sudden the waveform skips, moves backwards and forwards real fast, and will sometimes move back to the. The sounds are like very random scratching sounds. Then it will start playing again at normal speed. It happens randomly and can happen on a track multiple times. This does not happen with other controllers and it does not happen if I use Serato.
 
there is a new ingine 5.0.2 update out now and i hope it fixes that issue
 
It is highly unlikely that this is the case, because in reality, the firmware has no impact on operation in computer mode.

Engine OS (firmware) isn't actually an operating system in the true sense of the term; it is simply a standalone application running on top of a Linux kernel.

When you turn on your SC6000Ms or any other Denon gear, the Linux kernel boots up, verifies communication with all the device's modules (buttons, screen, audio circuitry, etc.), and then launches the Engine OS application.

The audio and MIDI ports are then occupied by the Engine OS application. That is why, when you want to switch to computer mode, Engine OS must be shut down to free up those ports, allowing the software on your computer to access and control them.

This is why there is—and never will be—an "omnisource-style" quick switch on Denon equipment based on the RK3288 hardware.

So, as you now know, Engine OS stops running when you switch to computer mode; consequently, it no longer has any influence whatsoever on behavior while in that mode.

Therefore, theoretically, Engine OS updates should not be able to fix anything related to computer mode.

I’ve heard that new fixes related to MIDI 2.0—including the option to force the older MIDI 1.0 protocol for certain devices—are expected sometime in June or July.

I believe this is the only way we will get a solution.

Note: The silence from the VDJ team members on this subject is deafening. Aside from one comment stating that Gemini's explanations seemed fabricated, we haven't received anything constructive from them so far. On one hand, I tell myself that SC5000M/6000M users might be a niche group for them, and perhaps they don't really care. But on the other hand, it’s reassuring to see that other gear with motorized platters seems to be having issues too.

Maybe if Pete from the Microsoft team stops by, he can tell us a bit more about this specific problem.
 
Great info mate thx for that
and am just really curious to know why inmusic can do an update for some gear and not to update their drivers to fix all of this mess. and being silent on the issue since it occurred.
 
They keep buying companies but don't have a coding team nearly big enough to cope. They also don't seem to see the benefit of supporting legacy products. Support are slow and never offer solutions.

Just my personal thoughts and experiences after owning their gear.
 
Ian Wild wrote :

I’ve heard that new fixes related to MIDI 2.0—including the option to force the older MIDI 1.0 protocol for certain devices—are expected sometime in June or July.

I believe this is the only way we will get a solution.


This will most likely be the fix, and what should have existed in the first place from Microsoft given they were planning to make such a major change.
Remember, things were working before the Microsoft updates (albeit not efficiently but they were), the updates basically upheaved an entire category of devices - that's not an easy fix to do in a short time.
 
kradcliffe wrote :
They keep buying companies but don't have a coding team nearly big enough to cope. They also don't seem to see the benefit of supporting legacy products. Support are slow and never offer solutions.

Just my personal thoughts and experiences after owning their gear.


In the specific case of the sc5000/M and 6000/M players, these models are class compliant and therefore do not require any specific drivers. So InMusic can't do much on this side.

Unfortunately, I don't have a PC running Windows 10 on hand to check but I'm almost sure that it would work as it should on the latter.

Microsoft has really created quite a mess for a good number of DJs without even worrying about compatibility with existing hardware. They come in, launch their wonky thing and then tell the builders, if there are any problems it's your problem and deal with it!

I carried out some tests with the EngineOS 5.0.2 update and the latest VDJ build 9480 and as expected it still does not resolve this problem.
 
I agree with both Ian and VinylTouch. inMusic drivers were working before Microsoft kicked off the chaos in January. OK maybe they weren't written strictly to spec, but it was a hole in the OS that allowed them to run.

There's an issue over on the NI forum at the moment with one of their ASIO drivers too, as the Microsoft updates have blocked it. Cue lots of people blaming NI.
 
groovindj wrote :
inMusic drivers were working before Microsoft kicked off the chaos in January. OK maybe they weren't written strictly to spec, but it was a hole in the OS that allowed them to run


That's a fair point but you'd think that in that 14 years ish this would have been picked up and rectified.

For me it's more the inaction on in-music's side since the driver update that's the issue as they should have issued a patch so people could get working again straight away instead of waiting for investigations and updates.

Thankfully after 27 years of being a DJ on Windows I had updates blocked anyway so my MCX8000 worked as normal.
 
Of course you're going to blame inMusic because that's what you do 🤷‍♂️

If the Windows OS was properly written in the first place, the drivers would have been.

I suppose this means you also blame Hercules and Native Instruments for the problems they've had?

Tools like loopMIDI and RTP-MIDI also had issues. Notation, Ableton, Studio One, Kontakt, Dorico. Must be their fault too, right?
 
After many years of running small businesses I realise you can't keep just blaming others. When things happen with third parties I still feel the onus is on you to provide a solution as the customers are billing you not the person who caused the issue.

I bought my first Denon products in the late 80s and the company that currently own the brand are nowhere near the same for quality or deliverability.

Each to their own I guess.
 
kradcliffe wrote :
the onus is on you to provide a solution


You mean like Atomix did with their patch (that was then nixed again by Microsoft)?

The Traktor users are blaming NI for the ASIO driver issue, but NI are having to liaise with Microsoft to fix it, and MS are clearly in no hurry to help - the problems are still ongoing more than six months after they started, and Pete has talked about further things being released into July and even August.

What's more, the affected NI controller was actually designed to use WASAPI, and despite that info being on the NI site and posted several times by staff, people are still moaning. 🤷‍♂️
 
Another issue I’ve just noticed is that it is now impossible to switch to Standalone mode (EngineOS) on either of the two SC6000Ms without VDJ crashing. You used to be able to do this without any problem, but now VDJ crashes and stops responding.

The same thing happens both on my laptop with my personal setup and on the club's PC with its own Denon DJ setup.

This further reinforces my belief that there is a genuine issue related to MIDI 2.0.
 
35%