A lot to go at there! A few clarifications below, I'll try your suggestions later - ATM, I've hooked up the Nvidia sound to the desktop speakers (rather than the USB input) to try and eliminate any 'USB problem' as the cause - see next post.
xcasxcursex wrote:Darn, you can't catch a break can youSorry to hear it's not sorted yet. I put a TL;DR at the bottom for you in case you're growing tired of reading my long explanations
Wise again. All too many troubleshooting posts online basically are a bunch of random guesses and that's not really the right way to go about things. If you guess right, then that's a shortcut but if you guess wrong, you're just wasting time, and might even break things or mask the problem....So, it's basically gambling, and with bad odds. Following a sensible process to actually define and reproduce the problem is the way to go. I know it can be tedious so hang in thereCook1e1412 wrote:I am disinclined to start just changing settings at random...
You've done everything right, I notice you even went back to stock-as-a-rock 44k1@16b, and it still not working is kinda strange. I guess one upside of this is that while all of this is showing that something's wrong with your computer, fixing it for VM is going to fix it for everything else, too.
I honestly don't believe it's anything to do with the computer - the problem's persisted through a change of MB and processor (essentially a new computer) and of course a new installation of Windows.
There is still the possibility that both of your USB devices are causing problems, it would be good to have a known-good soundcard/driver to test against (like the nvidia HDA or perhaps the realtek (perhaps not reliable enough to be calling it 'known-good') with some normal headphones plugged in).... but MME tends to be very stable (slow, but stable) and you're still seeing this with MME drivers so what you learned 1) and 2) are strong here.
Done - see below
So, let's assume (Just saying that word makes me feel like hindsight will punish me for it, but given 1) and 2) it's a fairly safe assumption) that it's unlikely that two completely different devices just happen to have the exact same problem, then the next step is to look at what those devices do have in common - as in, what's the one thing that's breaking, that breaks both USB devices?
Two things jump to mind immediately - the first is obvious; they're USB devices. Perhaps there's something wrong with your USB controller. Secondly, upstream from there is of course the CPU. I can't help but wonder if maybe this is something overloading the CPU (or taking priority over VM, although that shouldn't happen with windows' defaults - have you made any windows 'tweaks' that might be changing CPU priority/affinity/etc?).
Nope. All seems well with the USB system
If the USB is the problem, there's a strong chance there'd be a message about it in the windows event viewer (Under Windows Logs... System). If it's CPU overload, Task manager will tell you. You can just leave task manager running in the background and then switch to it when the glitch happens, and see if the CPU spiked to 100%
I may try this anyway, just in case there's a clue
Moving on up the chain from there, if it were an issue with the virtual device somehow, you could cut voicemeeter out of the situation here. If you close VM, then the virtual cable will send its input to its output, and then you can use windows to redirect that to the USB sound device. Here's a screenshot of how that looks on my PC, I've used VAIO3 but you should just use the normal default, and I've set the output to my TV but you should select your USB device:
I'll try that if the problem remains with the Nvidia sound as A1(I suspect it will)
Listen.png
Again, leave the config screen open (to check for push loss) and task manager running (to check for overload), but this will give you a chance to see if the virtual device is glitching out without VM being in the loop.
The only other thing that immediately comes to mind is perhaps the player you're using is handling the device in a strange way. I'd be inclined to try and test this with something really standard, like a browser, or VLC or something like that.
It's just the same listening to YouTube or internet radio via the browser. All the sound is directed the same way as VM is the default sound device.
There is a tool, I know from my old days as a musician and is also common for gamers these days: LatencyMon. This tool is specifically designed to test a PC to make sure the system is handling events in a timely fashion and that the PC is capable of handling realtime audio, so it's quite appropriate here. The short version of how to use it is: While the PC is idle, run the app, click the green play button up the top, let it run for a few minutes, then click the stop button. It should tell you outright in the results of the test, if it found any problems.
Again, I'll give that a go next
TL;DR:
Check event viewer for USB errors
Check task manager for CPU overload
Remove/undo any CPU-related tweaks
Try Cutting VM out of the loop (see image)
Use a known-good player
Test your PC with LatencyMon
I'm really interested to hear what Vincent has to say about the VM recorder having that 'sped-up' effect, while the user hears distortion. Obviously, audio buffers are not getting to VM (we can see this from the VAIO device push loss), but how that recorder works under the hood is closed source do he would have to tell us what that means..... Is it just that there is no audio, so the recorder writes nothing, and this results in less audio in the same amount of time (a sped-up effect because the missing parts are missing, as opposed to being silent or duplicated old buffers)? Or is it a clock/timing issue? (the clock is running faster than the audio arrives, so it drops some audio buffers)?
LatencyMon now shows 'Wdf01000.sys' and 'ACPI.sys' to be causing the excess latency.
If they're important, I'll run again.
I'll have another go...