DSDPlus Recording - broken choppy audio and stops the scan?

[enCrypt]

Hi All,
Recent upgrader to DSD+ Fastlane and love it mostly apart from I'm getting terrible results with recording.
I'm trying to ID a load of unknown freqs that I've heard brief activity on, as well as ID some TGs on a known CAP+ system so I have a Windows 10 VM running 24/7 running two instances of the latest Fastlane, one sat on the CAP+ system control channel and the other instance scanning around the unknown freqs.
My setup -
ESXi Server (with tons of resource / overkill) running a Windows 10 VM with 4 x Xeon vCPUs, 8GB RAM, (virtual)HD Audio sound card (this might be my problem?)
Every recording has a rythmical choppiness to it, will try to upload an example soon...

I've tried .wav and .mp3, same issue.
I've tried just running recording on one of the two instances, same issue.
I'm currently trying just one instance running scanning through everything including the CAP+ system but noticed it recorded something early this morning and stopped the scan? Is that normal?

If I cannot solve it I'll try running the same thing on a physical machine I think.
Is anyone else running DSD+ on a VM?

Thanks
enCrypt

 

[enCrypt]

Here is an example of my recordings, they are all like this...

 

[slicerwizard]

Sounds like the decoding quality is terrible. A raw audio sample would be better for diagnostic purposes.

 

[enCrypt]

Thanks Slicerwizard, how would I go about getting that please?

 

[slicerwizard]

The R key in DSD+ starts/stops raw audio recording. Or use the Input menu's recording options.

 

[Kazzaw]

Screenshots of your FMPx windows are also helpful

 

[enCrypt]

Thanks both,
All of these freqs and the CAP+ system are pretty quiet so it might take me a while to get the required extra files.
I'll keep monitoring it and come back to this thread.

 

[enCrypt]

So it looks like I must have been getting a lot of lag / performance issues trying to do this on an ESXi VM, which is a shame.
My ESXi host server, as already stated, is way over specced in regards to CPU and RAM resources but it seems the issue was with "passing through" the USB (2.0) port from the host server to the Windows 10 VM.
When I ran rtl_test on the VM, both of my RTL sticks were racking up lots of errors...
I've since built another standalone, physical machine and connected the RTL sticks to it and set it up the same as the VM.
This has resulted in much better audio on recordings (although when I have 2 instances running at once, the 2nd one still does the same wierd choppy recording thing?)
rtl_test on both dongles on the physical machine is fine, one logs 3 errors then stops, the other logs 5 then stops...
I can live with just scanning around everything using one dongle.

Still getting the scan stopping on its own sometimes though which is a bit annoying...

Thought I'd update in case anyone else was thinking of trying the same...

Cheers
enCrypt

 

[Kazzaw]

Reach out to DSDPlus via email and they may be able to look into it for you, I have found them helpful with odd knacks and requests

 

[serial14]

I previously tried passing through USB audio devices and an RTL SDR from the ESXi host to a VM and got choppy results as well. I eventually found some VMWare documentation( and didn't save the link ) that stated there are limitations on their USB passthrough. Basically they only support block devices & serial port converters. Streaming devices like Audio and RTL-SDR had no gaurenteed performance to them.

I'm in a similar situation to you, I have plenty of ESXi resources laying around but can't utilize them for my radio hobbies. Its unfortunate.