VAC SIGNAL NOT STEADY

USB headsets to digital audio workstation software...
User avatar
w-u-2-o
Posts: 786
Joined: Fri Mar 10, 2017 1:47 pm

Re: VAC SIGNAL NOT STEADY

Postby w-u-2-o » Fri Dec 01, 2017 12:10 am

Very true, Stu. Unfortunately the VAC control code dates from the legacy Flex days and is total spaghetti :(

73,

Scott
w9mdb
Posts: 30
Joined: Sun Apr 09, 2017 5:53 pm

Re: VAC SIGNAL NOT STEADY

Postby w9mdb » Thu Dec 28, 2017 4:59 am

I started having problems too. Latency mon sees no problems. 2048 buffer size didn't change things. But dropping the Primary sample rate to 96000 did solve it. Recording the transmission could see half a dozen dropouts running FT8 on WSJT-X.

de Mike W9MDB
User avatar
Tony EI7BMB
Posts: 108
Joined: Sun Apr 09, 2017 2:31 pm
Location: Dublin
Contact:

Re: VAC SIGNAL NOT STEADY

Postby Tony EI7BMB » Thu Dec 28, 2017 1:48 pm

Mike if you have time could you post a pic of what the drop outs look like on the waterfall , think I may be seeing the same here?
User avatar
w-u-2-o
Posts: 786
Joined: Fri Mar 10, 2017 1:47 pm

Re: VAC SIGNAL NOT STEADY

Postby w-u-2-o » Thu Dec 28, 2017 2:28 pm

w9mdb wrote:I started having problems too. Latency mon sees no problems. 2048 buffer size didn't change things. But dropping the Primary sample rate to 96000 did solve it. Recording the transmission could see half a dozen dropouts running FT8 on WSJT-X.

de Mike W9MDB

Mike,

I saw where you posted in the other thread that your LatencyMon results are OK. I'm going to assume that you read through my entire VAC tutorial as well? I.e., that all your settings are correct, that you are 48KHz "clean", etc.

If so, then the only thing I can suggest is that, based on the improvement in your situation when changing the primary sample rate to 96KHz, your computer simply isn't powerful enough. Of course, now you are probably going to tell me that you have some sort of i7, crypto smashing, bit coin mining, kind of machine ;)

There are three basic sources of dropout (RX or TX, it's the same):

1. Non-optimal buffer settings (primary, VAC, latency, DSP). These will cause under and overflow type errors thereby resulting in dropouts.
2. Sound driver related issues (PortAudio), which can lead to PortAudio related buffer under and overflow type errors. Other than selecting sound drivers and checking your machine with LatencyMon, you have no direct control over this.
3. DSP processing related issues that caused by untimely PowerSDR thread execution. Again, this is the sort of thing you check for with LatencyMon, and you have no direct control over it other than to lower CPU load, things that affect CPU thread execution latency, and creating a faster, more powerful computer.

There used to be a fourth issue, which is the Ethernet packet out of order problem, but that has been fixed for a few versions now.

It's worth noting that because of the somewhat less than optimal architecture of PowerSDR DSP processing, it can be more challenging to run than even more complex sound related software such as Pro Tools or other DAWs. Much, if not all, of this has been fixed in Thetis. Unfortunately the Protocol 2 firmware necessary for Thetis is not ready for prime time yet.

This issue is one of the reasons I decided to build a faster PC.

73,

Scott
w9mdb
Posts: 30
Joined: Sun Apr 09, 2017 5:53 pm

Re: VAC SIGNAL NOT STEADY

Postby w9mdb » Thu Dec 28, 2017 2:36 pm

Here's my system calling CQ top one no dropouts, bottom one has some. I'm running 48kHz sampling right now and still seeing dropouts but not as bad. Latency mon shows no problems. I see this show up as power variation on Fwd Pwr and the "flashing" of the spectra as these sharp transitions occur. Going to do some more testing here. Latencymon shows no problems on my system.
Would be nice if there was some sort of dropout detection in PowerSDR as I'm wondering how many people are experiencing this? I had the problem a few months ago and then a reboot seemed to fix things. But now that doesn't fix it either.
de MIke W9MDB
Image
AB2EZ
Posts: 60
Joined: Sun Apr 09, 2017 2:29 pm
Location: Princeton, NJ

Re: VAC SIGNAL NOT STEADY

Postby AB2EZ » Thu Dec 28, 2017 3:56 pm

All

VAC1 + FT8 has been working flawlessly (no glitches on the waterfall, etc) for about 1
month now. I have installed the last several HPSDR updates without any problems. As I cycle through various bands and band segments... VAC1 automatically turns on or off... depending upon how I have set it for those modes/band segments. I have installed several Windows 10 updates. I have turned the HPSDR application off each evening. I have restarted the computer from time to time.

No problems EXCEPT if I turn VAC1 off and on manually (which I don't do). Turning VAC1 off and on manually causes a return of the waterfall glitches and various other problems...which requires me to "fiddle" with the sampling rate and the buffer sizes to fix.

I am using an ANAN 10E and a three year old I7 Dell computer. The if sampling rate is set at 192k samples per second. Latency monitor shows no problems. It can run for several hours before it registers a hiccup. Every once in a while, the transmit waterfall registers a single glitch during an FT8 transmission... which I assume is due to an overflow of one of the digital audio buffers. I.e. the clock inside the Dell computer is running about 18ppm fast compared to the GPS-disciplined clock that is driving the ANAN 10E.

Stu
Last edited by AB2EZ on Thu Dec 28, 2017 5:05 pm, edited 1 time in total.
User avatar
w-u-2-o
Posts: 786
Joined: Fri Mar 10, 2017 1:47 pm

Re: VAC SIGNAL NOT STEADY

Postby w-u-2-o » Thu Dec 28, 2017 4:10 pm

AB2EZ wrote:No problems EXCEPT if I turn VAC1 off and on manually (which I don't do). Turning VAC1 off and on manually causes a return of the waterfall glitches and various other problems...which requires me the "fiddle" with the sampling rate and the buffer sizes to fix.
This is a known bug. You can fiddle, or you can just restart PowerSDR. It's a huge pain for people who switch between VAC and non-VAC operations. I'm always in VAC mode so it doesn't affect me ;)

73,

Scott

Return to “Digital ("Virtual") Audio”