VAC SIGNAL NOT STEADY

USB headsets to digital audio workstation software...
User avatar
Prem
Posts: 76
Joined: Tue Apr 11, 2017 11:57 am
Location: UAE
Contact:

VAC SIGNAL NOT STEADY

Postby Prem » Fri Nov 03, 2017 1:00 pm

Hi All,

My Hermes SSB signal ok with Mic plugged to front jack. but Audio not ok when I use my external B1 studio mic thru USB interface and Voice meter banana. The set up I had used earlier. Last day I reset database and these after this isssue come.

Please below link for a video to see the screens, during digital mode transmission. Similar unsteady waveform with SSB also.

http://www.youtube.com/watch?v=NBu4QO0OP6w

73s,
Prem, A65BK
User avatar
w-u-2-o
Posts: 5540
Joined: Fri Mar 10, 2017 1:47 pm

Re: VAC SIGNAL NOT STEADY

Postby w-u-2-o » Fri Nov 03, 2017 2:40 pm

Prem,

The problem appears to be that you have not properly set up all of the sampling rates, buffers sizes, and other parameters necessary to ensure the smooth flow of audio between PowerSDR and the digital mode software.

Everything you need to know is in my VAC Tutorial.

Pay particular attention to Sections 4, 8 and 7, in that order. If you don't get good results in Section 4 you will not be happy later. Follow the instructions carefully and precisely in Section 8. Section 7 is optional, but educational.

Do be sure you route receive audio to your ear via the PC speakers using VMB at least temporarily to ensure that receive audio quality is good. Similarly, use MON to ensure your transmit audio quality is good to your ear. Your ear can hear every click, pop and glitch much better than the displays can show you.

73,

Scott
AB2EZ
Posts: 99
Joined: Sun Apr 09, 2017 2:29 pm
Location: Princeton, NJ

Re: VAC SIGNAL NOT STEADY

Postby AB2EZ » Fri Nov 03, 2017 3:06 pm

Prem

I have the same problem with my ANAN-10e... with VAC... using WSJT-X with VMB.

I have everything set up in accordance with Scott's VAC tutorial

VAC1 + VMB seems to work fine for Scott. I am beginning to believe that this may be a problem with the details of how VAC works in Hermes boards. Perhaps, it is associated with the smaller FPGA.

Sometimes I can eliminate the instability by trying a lower value (e.g. something between128 samples and 1024 samples) for the VAC1 buffer.

However, even when I do the above, I can still see glitches every few seconds on the transmit waterfall.

Note:

In order to view the transmit waterfall, I set the upper range of the waterfall to +10 dBm.... and the lower range to -50 dBm. Doing that makes the waterfall useless for monitoring the received signal... but very useful for monitoring the transmit signal.

I have the VMB virtual audio cables both set to the 48kHz internal sampling rate. All audio "recording" and "playback" devices are set to 16 bit 48kHz "compact disc quality".

Everything works fine (no glitches) using a non-VAC configuration. I.e speaker output connected to the analog input of my digital audio interface, and the analog headphone output of my digital audio interface connected to the front panel microphone input of my ANAN-10. This even works fine using my computer's built in sound card and headset jacks as the digital audio interface to WSJT-X.

Stu
Last edited by AB2EZ on Fri Nov 03, 2017 5:10 pm, edited 1 time in total.
User avatar
w-u-2-o
Posts: 5540
Joined: Fri Mar 10, 2017 1:47 pm

Re: VAC SIGNAL NOT STEADY

Postby w-u-2-o » Fri Nov 03, 2017 5:09 pm

There is absolutely nothing associated with the firmware or hardware that has anything to do with the operation of the VAC interface. The VAC interface is entirely contained within and controlled by PowerSDR and the performance of your PC and operating system. In other words, it has nothing to do with whether you run a Hermes, Angelia, Orion or Orion MkII.

Stu: have you used LatencyMon and DPC Latency Checker to confirm that your PC hardware and Windows OS configuration are suitable for real-time audio? If not, or if you have and have detected problems, there is some discussion in this thread.

If you get a clean bill of health from those app's, then it is all about choosing the correct settings for Primary Buffer Size, VAC Buffer Size, Sample Rate, and Buffer Latency. If you are using VMB, it is also about choosing the correct settings for the Windows Sound Control Panel instances, and also the VB Audio Virtual IO control panel settings. How to do this is detailed at my tutorial page. Finally, I strongly dis-recommend ASIO4ALL, that driver is junk.

73,

Scott
User avatar
Prem
Posts: 76
Joined: Tue Apr 11, 2017 11:57 am
Location: UAE
Contact:

Re: VAC SIGNAL NOT STEADY

Postby Prem » Fri Nov 03, 2017 5:26 pm

Hi,

When I load my Old database which was working well with my Flex 15oo and even my Old Hermes Database, this issue got resolved !

But even after database reset and building new , this issue comes !

73s

Prem, A65BK
AB2EZ
Posts: 99
Joined: Sun Apr 09, 2017 2:29 pm
Location: Princeton, NJ

Re: VAC SIGNAL NOT STEADY

Postby AB2EZ » Fri Nov 03, 2017 5:30 pm

Scott

Everything (I have checked every step) is set up in accordance with your VAC tutorial. I do not have ASIO4ALL installed on my computer. I have adjusted both of the VMB Virtual I/O Control Panels for 48000 samples per second... and that is what shows up on the VMB display. All audio interface settings (VMB settings, Recording Devices, Playback Devices) are set to 16 bit 48000 samples per second.

I have run Latency Monitor... and all of the results are in the green. I just ran it again for 17 minutes.. and everything is green. The highest measured interrupt-to-process latency is 680 us, The highest ISR routine execution time is 305 us. The highest reported DPC routine execution time is 599 us. The total hard pagefault count is 0. I'm using Windows 10... so I can't run DPC Latency Checker

"There is absolutely nothing associated with the firmware or hardware that has anything to do with the operation of the VAC interface. The VAC interface is entirely contained within and controlled by PowerSDR and the performance of your PC and operating system. In other words, it has nothing to do with whether you run a Hermes, Angelia, Orion or Orion MkII."

But... the Hermes HPSDR application is not the same as the Angelia HPSDR application... and perhaps there is some subtle difference that affects VAC1.

Stu
User avatar
w-u-2-o
Posts: 5540
Joined: Fri Mar 10, 2017 1:47 pm

Re: VAC SIGNAL NOT STEADY

Postby w-u-2-o » Fri Nov 03, 2017 8:15 pm

AB2EZ wrote:But... the Hermes HPSDR application is not the same as the Angelia HPSDR application... and perhaps there is some subtle difference that affects VAC1.

Stu,

I'm not sure I understand this statement. Are you referring to firmware or software? If firmware, then, yes, it is different, but those differences do not contain any dependencies that could affect VAC. At it's most elemental level, the firmware accepts an IF data stream from PowerSDR, and generates an IF data stream to PowerSDR. These data streams remain unchanged whether you use VAC or not. If there was a problem with either of those data streams it would manifest itself as a problem when using the audio I/O built into the radio as well.

To put an even finer point on it, the firmware also produces an audio data stream from the audio CODEC (from the Mic), which is delivered to PowerSDR, and the firmware accepts an audio data stream from PowerSDR to the audio CODEC (for the speakers/headphones). These data streams remain unchanged whether you use VAC or not.

As all of the radios, Hermes, Angelia, et al, use the same communications protocol, they appear the same to PowerSDR with respect to these data streams, both IF and audio. Only the control information is different.

Thus problems with the audio path from PowerSDR to/from other applications on the PC are completely independent of radio firmware.

If you mean software, then the application software, PowerSDR mRX PS (current release 3.4.2) is identical in all respects associated with the processing of this data regardless of the radio in use. Again, only the control data is different.

73,

Scott
AB2EZ
Posts: 99
Joined: Sun Apr 09, 2017 2:29 pm
Location: Princeton, NJ

Re: VAC SIGNAL NOT STEADY

Postby AB2EZ » Fri Nov 03, 2017 8:30 pm

Scott

I meant the software.

I agree that all of the software relevant to audio processing ought to be the same... and yet.... on my ANAN-10e... the thread associated with the VAC1 functionality of the overall application is behaving as if, every second or so, the smooth flow of digital audio samples is being held up (very briefly) by more than can be accommodated by the user-accessible buffers (i.e. the buffers that I can set). Therefore, I see a very brief "glitch" in the waterfall (where the audio appears to be dropping to zero value) every second or every few seconds.

When you set up the waterfall as I suggested (upper level = 10 dBm and low level = -50dBm) this behavior is easy to see.... both in terms of when the glitches occur, and how long they last.

Stu
User avatar
w-u-2-o
Posts: 5540
Joined: Fri Mar 10, 2017 1:47 pm

Re: VAC SIGNAL NOT STEADY

Postby w-u-2-o » Fri Nov 03, 2017 8:48 pm

Do you have more than one radio to try this on using the identical setup: same PowerSDR, same PC, same everything (except database)? If so, and if it demonstrates that there is a difference, then this would suggest a corrupt database associated with your 10E setup.
User avatar
Prem
Posts: 76
Joined: Tue Apr 11, 2017 11:57 am
Location: UAE
Contact:

Re: VAC SIGNAL NOT STEADY

Postby Prem » Sat Nov 04, 2017 1:19 am

Scott,

I use Flex 1500 and PSDR associated with Flex Radio. Then our Hermes and PSDR mRx for it. Both Run in same PC.
I think both Database talk each other and in same folder !! ??

Any particular setting to be done in PC folder or Path for Data base ??

73s

Prem
User avatar
Prem
Posts: 76
Joined: Tue Apr 11, 2017 11:57 am
Location: UAE
Contact:

Re: VAC SIGNAL NOT STEADY

Postby Prem » Sat Nov 04, 2017 12:57 pm

Hi Team,

Today I could understand the trouble with my VAC signal issue vanishes, when I changed from Windows WDM-KS to MME.
With WDM-KS even after many different combination tried with various buffer setting, I could not get it working clean !!

Amy be I have to spend more time !

Any suggestion on easy setting with WDM-KS ?
I did Latency monitor test and my PC pass the test !

Rds, Prem
User avatar
w-u-2-o
Posts: 5540
Joined: Fri Mar 10, 2017 1:47 pm

Re: VAC SIGNAL NOT STEADY

Postby w-u-2-o » Sat Nov 04, 2017 2:13 pm

Just use MME if you can't find buffer settings that work for you with WDM-KS. Low latency is not required for any digital mode except for ARQ modes like WINMOR.

73,

Scott
User avatar
Prem
Posts: 76
Joined: Tue Apr 11, 2017 11:57 am
Location: UAE
Contact:

Re: VAC SIGNAL NOT STEADY

Postby Prem » Sat Nov 04, 2017 4:19 pm

Scott,

I will be using VAC for SSB for processing my audio thru VMB and even DAW.

Rds,

Prem
User avatar
w-u-2-o
Posts: 5540
Joined: Fri Mar 10, 2017 1:47 pm

Re: VAC SIGNAL NOT STEADY

Postby w-u-2-o » Sat Nov 04, 2017 7:50 pm

Prem wrote:I will be using VAC for SSB for processing my audio thru VMB and even DAW.

I recommend you obtain a good quality sound interface that supports ASIO. This will eliminate any problems with MME or WDM. This is my top recommendation:

https://www.music-group.com/Categories/Behringer/Computer-Audio/Audio-Interfaces/UMC202HD/p/P0BJZ

Amazon has them in the US for $60, which is quite reasonable. I have plugged powered speakers into mine (JBL LSR305's), and a Behringer B1 microphone, and everything sounds like a million Euros on both receive and transmit ;)

With the advent of the new CFC processor in PowerSDR, you really don't need a DAW anymore, although it is still very fun to play with that stuff :)

73!

Scott
User avatar
Prem
Posts: 76
Joined: Tue Apr 11, 2017 11:57 am
Location: UAE
Contact:

Re: VAC SIGNAL NOT STEADY

Postby Prem » Sun Nov 05, 2017 5:44 am

Hi Scott,
I will get one ASIO supported interface.


73s,
Prem
AB2EZ
Posts: 99
Joined: Sun Apr 09, 2017 2:29 pm
Location: Princeton, NJ

Re: VAC SIGNAL NOT STEADY

Postby AB2EZ » Mon Nov 06, 2017 6:41 pm

Scott
et. al

Somehow. VAC is now working with WSJT-X and VMB (i.e. very few glitches on the transmit waterfall display). Everything is configured as before. However, I did switch back and forth between MME => ASIO => MME on the VAC1 driver settings.... and briefly tried transmitting with the VAC1 driver set to ASIO. (ASIO didn't work, in terms of producing a stable FT8 output on transmit). Right now, the buffer is set to 1024 samples... and the "buffer latency" "manual" box is not checked.

Perhaps, switching the VAC1 driver back and forth between MME and ASIO managed to unstick/reset something in the VAC configuration data.

Stu
User avatar
w-u-2-o
Posts: 5540
Joined: Fri Mar 10, 2017 1:47 pm

Re: VAC SIGNAL NOT STEADY

Postby w-u-2-o » Mon Nov 06, 2017 10:26 pm

Stu,

I know you've read my tutorial. It does cover the fact that there is a bug in the code that causes the buffering to sometimes not properly operate, and that the buffering can be reset by using the "POWER" button, or the VAC button, or by making any change in the VAC settings. Worse, it can fool you, because receive can be working fine, but transmit could be screwed up. Always best to use MON to test both.

73,

Scott
AB2EZ
Posts: 99
Joined: Sun Apr 09, 2017 2:29 pm
Location: Princeton, NJ

Re: VAC SIGNAL NOT STEADY

Postby AB2EZ » Sun Nov 12, 2017 6:54 pm

Scott

et. al.

VAC1 + VMB + WSJT-X (FT8) has been working flawlessly on transmit (a very clean/stable panadapter display and waterfall display* on transmit... with no glitches) for 5 days

But...

Since my prior post on November 6, I had a problem the next day (November 7) where lot's of glitches, and various unstable behaviors (when using VAC1) returned. Since resetting the HPSDR v3.4.2 database didn't help, and turning off HPSDR and restarting the computer didn't help... I decided to delete the HPSDR application, and to install a new copy of HPSDR v3.4.2. This fixed most of the problems (even though the prior database was automatically reinstalled).

Then, following Scott's advice... I "played around" with various combinations of VAC1 buffer size, etc. I stumbled into a combination that has worked great (in my particular ANAN-10e setup) for the last 5 days: buffer size = 512, and buffer latency "manual" box NOT checked.

I'm going to install the new HPSDR version 3.4.3 in a day or so,,, and we'll see how that works out.

*Note that I have the waterfall levels set at: low level = -60, and high level = +20 so that I can see a useful transmit waterfall.

Stu
AB2EZ
Posts: 99
Joined: Sun Apr 09, 2017 2:29 pm
Location: Princeton, NJ

Re: VAC SIGNAL NOT STEADY

Postby AB2EZ » Fri Nov 17, 2017 7:17 pm

Scott
et al.

I'm still trying to determine what causes VAC1 to behave erratically (sometimes it works... and sometimes it doesn't) when I use VAC1, WSJT-X, and a pair of virtual cables from VB Audio to interconnect them. I.e. when either the pair of virtual cables that are those that are part of VMB, or a separate pair of stand-alone virtual cables.

One change that I just made was to: lower the "main audio" sampling rate from 384k samples per second to 192k samples per second, close the HPSDR application, and then reopen the HPSDR application. That seems to make VAC1 work perfectly (so far) with WSJT using a pair of VB Audio virtual audio cables.

I've been using 384k samples per second for many months... without any problems. But, as I understand it:

When transmitting... Hermes (ANAN-10e) employs three (3) "main audio" streams (including two for Pure Signal)... passing... via the Ethernet connection... between the computer and the ANAN-10e. Each of these streams has an average payload data rate of: the "main audio" sample rate x 16 bits per sample x 2 (for I and Q) bits per second. At a "main audio" sample rate of 384k samples per second...each steam has an average data rate of 384,000 x 16 x 2 bits/s = 12.3 Mb/s. The three streams, collectively, have an aggregate average data rate of 36.9 Mb/s.

That is less than the nominal Ethernet data rate of 100Mb/s... but taking into account factors such as buffering and Ethernet packet overhead... I suspect that Ethernet congestion (even though the VAC functionality takes place in the computer) is a causing the erratic VAC1 behavior that I observe in my application when the "main audio" rate is set too high.

Stu
Last edited by AB2EZ on Sat Nov 18, 2017 12:29 am, edited 2 times in total.
User avatar
w-u-2-o
Posts: 5540
Joined: Fri Mar 10, 2017 1:47 pm

Re: VAC SIGNAL NOT STEADY

Postby w-u-2-o » Fri Nov 17, 2017 10:09 pm

Stu,

If a problem with the Ethernet link was the culprit, then you would hear these dropouts on speakers/headphones plugged into the radio. If you don't hear the problems there, then it can safely be assumed to be associated with VAC functionality and not Ethernet functionality.

73,

Scott
AB2EZ
Posts: 99
Joined: Sun Apr 09, 2017 2:29 pm
Location: Princeton, NJ

Re: VAC SIGNAL NOT STEADY

Postby AB2EZ » Sat Nov 18, 2017 7:35 pm

Logically... I agree that if everything is working as it should, congestion-related problems with the Ethernet should affect both the VAC1 receive audio path and the non-VAC1 receive audio path simultaneously. I.e. both of these depend upon the same "Primary Audio" data stream... and (presumably) nothing specifically related to the VAC1 functionality moves over the Ethernet connection.

Changing the "primary audio" (which I referred to, incorrectly as "main audio" in my previous post) sample rate to a lower value did not provide a permanent fix to the problem. After cycling VAC1 off and back on... I still had to fiddle with different combinations of the "primary audio" buffer size, the VAC1 buffer size, cycling between different VAC1 drivers and different VAC1 virtual I/O devices, cycling HPSDR power on and off, closing and reopening HPSDR, cycling VAC1 on and off... in order to get VAC1 to work properly with WSJT-X. I haven't yet tried changing the digital DSP buffer size.... as suggested in your tutorial.

Right now it is working... but if I do something like turning VAC1 off and back on, the problem will probably return... and I will have to start fiddling again to get VAC1 to work with WSJT-X. Turning HPSDR off, and back on (without changing anything else) doesn't seem to cause the problem to return.

The fact that fiddling around with different combinations fixes (temporarily) the problem suggests that there may be a sequencing/timing problem associated with the start-up of VAC1. In any event, hopefully this problem will be addressed in a future release of HPSDR.

I appreciate all of the efforts that the volunteers have put in to provide this wonderful application.

Stu
User avatar
w-u-2-o
Posts: 5540
Joined: Fri Mar 10, 2017 1:47 pm

Re: VAC SIGNAL NOT STEADY

Postby w-u-2-o » Sat Nov 18, 2017 9:57 pm

AB2EZ wrote:The fact that fiddling around with different combinations fixes (temporarily) the problem suggests that there may be a sequencing/timing problem associated with the start-up of VAC1. In any event, hopefully this problem will be addressed in a future release of HPSDR.
While I 100% agree that it is not the most stable nor the easiest to adjust interface in the world, it would seem that the configuration of your PC is probably more to blame for the high degree of instability you are experiencing. I can freely adjust the heck out of my buffer settings and as long as I don't drop below a certain combination of primary and VAC buffer size (I'm unambiguously stable at Buffer Latency = 0 and DSP = 64, so those doesn't come into play) I don't experience these problems. VMB, Fldigi and WSJT-X come up perfectly 99% of the time. Every once in a great while I get an improperly initialized buffer on transmit. It only takes one or two cycles of the VAC button to kill off "Mr Roboto" :lol: Most of the other people that use fully virtualized audio see the same behavior as I do. So something is different or unique about your PC configuration, Stu.

That's the problem with PCs. They do not exhibit the same uniformity and stability as a toaster (not including internet enabled toasters, of course ;) )

73,

Scott
AB2EZ
Posts: 99
Joined: Sun Apr 09, 2017 2:29 pm
Location: Princeton, NJ

Re: VAC SIGNAL NOT STEADY

Postby AB2EZ » Thu Nov 23, 2017 4:55 pm

Update

My ANAN-10E. has been working flawlessly for the least 5 days using VAC1 => a pair of input-to-output VB audio virtual audio cables=> WSJT-X.
I can power-off HPSDR, and I have even sequentially installed the latest three HPSDR releases... without causing any instability problems

Primary audio is set to: 192k samples per second, and a buffer size of 2048.

VAC1 is set to: MME, Output = "VB Audio Cable B Input", Input = "VB Audio Cable A Output", sample rate = 48k, buffer size = 512, buffer latency (manual) = 20ms. [One could also use the virtual audio cables that are integral to VMB, instead of the VB Audio stand-alone cables]

The only thing that seems to set off the instability is: turning off VAC1, and then turning it back on. Doing that requires "fiddling" with various combinations of inputs, outputs, sampling rates, and buffer sizes to make the instability go away.

Happy holidays

Stu
User avatar
w-u-2-o
Posts: 5540
Joined: Fri Mar 10, 2017 1:47 pm

Re: VAC SIGNAL NOT STEADY

Postby w-u-2-o » Thu Nov 23, 2017 7:12 pm

That tracks almost exactly with the configuration here. 192KHz main sample rate. Primary buffer 256. VAC buffer 256. ASIO at 96KHz. Buffer Latency 0mS. VMB to/from everything (WSJT-X, Pro Tools, Fldigi, etc.) Same stability. Same occasional buffer initialization issues, primarily on transmit. That last issue is tricky, because receive nearly always sounds 100%, and I always need to remember to check transmit with MON for Dr. Roboto before operating.

Note also that the VAC 256 buffer size tracks along with the buffer size on the Behringer UMC202 interface, which is set to 256 and 96KHz.
AB2EZ
Posts: 99
Joined: Sun Apr 09, 2017 2:29 pm
Location: Princeton, NJ

Re: VAC SIGNAL NOT STEADY

Postby AB2EZ » Thu Nov 30, 2017 7:35 pm

Scott
et. al

An additional data point on this topic:

When I use the main GUI to toggle VAC1 off and back on... I have to fiddle with the VAC1 settings to get VAC1 to recover the clean functioning it had before I turned VAC1 off and back on.

BUT

When I change band segments by clicking on (for example) the "40" button... four times.... the configuration changes (as per the design intent of v3.4.6) from VAC1 on (as I have set it in the band segment that I am using for FT8) to VAC1 off (as I have set it in the four band segments that I am using for SSB, AM, and CW). When I click on the "40" button one more time, the band segment that I am using for FT8 returns, VAC1 automatically turns on, and the VAC1 functionality is clean.

Therefore, it appears that there is something different about how VAC1 automatically toggles off and on when changing band segments (or bands) v. toggling VAC1 off and on manually by clicking on the VAC1 button.

Stu
User avatar
w-u-2-o
Posts: 5540
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: 446
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
Mike W9MDB
User avatar
Tony EI7BMB
Posts: 651
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: 5540
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: 446
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
Mike W9MDB

Return to “Digital ("Virtual") Audio”