Digi mode audio problems (was: Identifying strange panadapter waveform)

USB headsets to digital audio workstation software...
JPPNews73
Posts: 9
Joined: Sun Jan 24, 2021 2:03 pm

Digi mode audio problems (was: Identifying strange panadapter waveform)

Postby JPPNews73 » Fri Oct 07, 2022 11:36 am

I'm running Thetis on an Anan 7000 DLE MKII running v2.9.06 x64 (Protocol2 v2.0.0) MW0LGE. While transmitting using WSJT-X I see the image in this YouTube link from my panadapter. So, what am I seeing here.

https://youtube.com/shorts/lQwSbEn7Im0?feature=share

73, Richard (JP) Pritchard, K5JPP
w9mdb
Posts: 446
Joined: Sun Apr 09, 2017 5:53 pm

Re: Identifying strange panadapter waveform

Postby w9mdb » Fri Oct 07, 2022 12:28 pm

I am convinced this is a bug in Thetis. I have the same problem. Toggling the Power button fixes it.
7000DLE MKII here with 2.1.23 firmware Protocol 2 v3.9.

I put my rig on a fiber optic adapter but my next step is a dedicated fiber optic link for the rig to see if it makes any difference.

One of these days maybe I can track it down.
Mike W9MDB
User avatar
w-u-2-o
Posts: 5539
Joined: Fri Mar 10, 2017 1:47 pm

Re: Identifying strange panadapter waveform

Postby w-u-2-o » Fri Oct 07, 2022 12:50 pm

There are no bugs in Thetis that should cause this behavior (except for the occasional VAC instability problem). WSJT-X and other digi modes run perfectly here.

Because you did not make a screen capture of the entire Thetis UI it begs a lot of questions:

1. Did you have PureSignal turned on in automatic mode (PS-A button on)? If so, don't do that, many digi modes don't play well with PS that way. Use two-tone and single cal to get a correction and let it ride.

2. Did you have your RF drive level very low, say under 10W? If so, then you can get this sort of behavior because of some limitations of the hardware design. Don't run your power so low this happens.

3. Is your virtual audio setup perfectly set up? Did you remember to go into the Windows control panel and change all virtual devices to 48KHz? Are you using conservative buffer sizes (super low latency is not required for digi modes)? Do you see any counts or, worse, active counting in the VAC over and underflow counters?

4. Is your network connection to the ANAN hardware good? Do you see a lot of SEQ errors? Look in Setup > Tests > Show SEQ log.

Once (if) you reply to this post I'm going to change the title of this topic to "WSJT-X transmit problems" and move it to the digi mode sub-forum.
User avatar
W2PA
Posts: 166
Joined: Sun Apr 09, 2017 6:34 pm
Location: LaGrangeville, NY
Contact:

Re: Identifying strange panadapter waveform

Postby W2PA » Fri Oct 07, 2022 12:50 pm

I see this too. It's certainly not just a panadapter artifact since you can hear it on the transmitted signal with an external receiver. Tuned away from the carrier beyond the passband it sounds like clicks.

It went away entirely after the "throttling" adjustment. Now it comes back randomly. For me, cycling the power button doesn't fix it. Nor does restarting the hardware. I've become convinced it's an Ethernet issue causing glitches in the data stream (or something like that). In experimenting with advanced settings for my NIC, I noticed that resetting the connection, as happens when you change anything on this tab, makes it go away. But it then returns again at a random time.

And it doesn't seem to have anything to do with VAC. It also happens to me with just a carrier in Tune mode.
73,
Chris, W2PA
User avatar
w-u-2-o
Posts: 5539
Joined: Fri Mar 10, 2017 1:47 pm

Re: Identifying strange panadapter waveform

Postby w-u-2-o » Fri Oct 07, 2022 1:47 pm

Chris, Richard: have either of you tried a dedicated, direct Ethernet connection to the ANAN hardware? I've found that fixed a lot of problems with UDP packet loss.

The openHPSDR thick-client architecture is simple and relatively low cost, but it levies a heavy burden on excellent network performance, particularly given the choice to use UDP instead of TCP for IF data transfer. It might have been better to accept the additional latency of TCP.
User avatar
W2PA
Posts: 166
Joined: Sun Apr 09, 2017 6:34 pm
Location: LaGrangeville, NY
Contact:

Re: Identifying strange panadapter waveform

Postby W2PA » Fri Oct 07, 2022 1:50 pm

Yes, I've been using a dedicated Ethernet card/connection since I first got the rig. Also static IP address.

For the moment I'm blaming Windows and its Ethernet driver. I'm hoping when I upgrade my PC it'll solve the problem (currently using an i7 4000-series PC).
73,
Chris, W2PA
User avatar
w-u-2-o
Posts: 5539
Joined: Fri Mar 10, 2017 1:47 pm

Re: Identifying strange panadapter waveform

Postby w-u-2-o » Fri Oct 07, 2022 3:47 pm

W2PA wrote:Yes, I've been using a dedicated Ethernet card/connection since I first got the rig. Also static IP address.

For the moment I'm blaming Windows and its Ethernet driver. I'm hoping when I upgrade my PC it'll solve the problem (currently using an i7 4000-series PC).
I've had really, really good performance from this board: https://www.amazon.com/dp/B07VXS49MG

Here are some of the settings I use, and I have Network Throttling Tweak enabled: viewtopic.php?f=22&t=4342&p=21860&hilit=metric#p21860
sv1jso
Posts: 36
Joined: Wed May 30, 2018 7:06 pm

Re: Identifying strange panadapter waveform

Postby sv1jso » Fri Oct 07, 2022 5:08 pm

This problem is VAC instability.

Mike
w9mdb
Posts: 446
Joined: Sun Apr 09, 2017 5:53 pm

Re: Identifying strange panadapter waveform

Postby w9mdb » Fri Oct 07, 2022 5:28 pm

And what makes you say it's VAC instability?
Not sure that would explain why resetting audio in Thetis fixes it (other than recreating the audio device to VAC).
VBAudio is used by audio professionals with multiple tracks without any such problems.
Mike W9MDB
User avatar
rbduck
Posts: 327
Joined: Tue Dec 03, 2019 1:49 pm

Re: Identifying strange panadapter waveform

Postby rbduck » Fri Oct 07, 2022 7:43 pm

JPPNews73 wrote:I'm running Thetis on an Anan 7000 DLE MKII running v2.9.06 x64 (Protocol2 v2.0.0) MW0LGE. While transmitting using WSJT-X I see the image in this YouTube link from my panadapter. So, what am I seeing here.

https://youtube.com/shorts/lQwSbEn7Im0?feature=share

73, Richard (JP) Pritchard, K5JPP


Is something similar to this appearing on any other bands?
Last edited by rbduck on Sat Oct 15, 2022 3:51 pm, edited 1 time in total.
73
Ruben
NB4R
Apache-Labs Anan 7000DLE MKII Black -- Thetis 2.10.3.6 dev_2 -- Windows 11
w9mdb
Posts: 446
Joined: Sun Apr 09, 2017 5:53 pm

Re: Identifying strange panadapter waveform

Postby w9mdb » Fri Oct 07, 2022 8:56 pm

Happens on all bands.
Mike W9MDB
User avatar
rbduck
Posts: 327
Joined: Tue Dec 03, 2019 1:49 pm

Re: Identifying strange panadapter waveform

Postby rbduck » Sat Oct 08, 2022 12:07 am

w9mdb wrote:Happens on all bands.


Take a look at this topic. viewtopic.php?f=9&t=4216&p=20530#p20530

Like I said I had something like this. It was like a very strong signal of some sort and showed up on every band. It wiped out virtually all the bands. To resolve it. I saved and exported my database. I then reset the database and imported the database back in to Thetis. I hope this information helps. In three years of Anan 7000 ownership, it has happened only twice.
73
Ruben
NB4R
Apache-Labs Anan 7000DLE MKII Black -- Thetis 2.10.3.6 dev_2 -- Windows 11
JPPNews73
Posts: 9
Joined: Sun Jan 24, 2021 2:03 pm

Re: Identifying strange panadapter waveform

Postby JPPNews73 » Sat Oct 08, 2022 11:18 pm

Scott, to answer your questions, one by one. Pure Signal Auto is not turned on. My RF drive is set at about 30 watts, as that is the stated max output for continuous duty modes like WSJT-X. I use Voice Meter Banana for Virtual Audio. Nothing new about this for me. And I have set 48K, buffer size 2048 for audio. VAC1 Monitor Overflows and underflows seem to be very stable. (I'm attaching a sequence log from today) I was getting quite a few sequence errors a couple of weeks ago but after I installed a new 8 port router, it all went away for a time. Now, obviously, it's back.
Since I didn't have this problem at all until recently, I have suspected that this new version of Thetis could be at fault, but what do I know? I am running a fairly old but refurbished Lenovo i-7 using 16 GB of DDR3 memory and a 1 GB SSD. Again, this behavior is all recent. I ran for the year and a half that I've owned the Anan without any issues like this..

Thanks for your help on this,
73, JP (Richard Pritchard) K5JPP
Attachments
Sequence Log.txt
(15.49 KiB) Downloaded 94 times
User avatar
vk6cpu
Posts: 35
Joined: Tue Jul 16, 2019 4:47 am
Location: Perth, Western Australia

Re: Identifying strange panadapter waveform

Postby vk6cpu » Sun Oct 09, 2022 1:51 am

I have been experiencing similar for a couple of years with my anan 8000.
These are my observations and what I have tried :-

I use both RX1 & 2 (vac 1 & 2) for TX and thanks to TCI can now monitor FT8/FT4/WSPR concurrently and switch apps for TX easily.

No observable pattern. Can effect either VAC1 or 2. Most times the other VAC is fine. RX is not affected

Only way to return the VAC to normal operations is closedown thetis and restart (sometimes need to cycle the Anan too).

Digital signal from application (JTDX etc) looks OK in other application (Spectrum LAb).

I always run Anan on a dedicated network port.

I had same issues last year on different PC - which was one of reasons I upgraded to current PC/setup - unlikely or just unlucky to be PC Hardware?.

HAve tried all flavours of audio settings MME/WDS/WDM. HAve tried all sizes of buffers and tweaks with VAC settings. Still occurs randomly.

So, I'm following this thread with interest and welcome any comments/insights others can suggest.
Attachments
Screenshot 2022-03-13 132148.png
Screenshot 2022-03-13 132148.png (944.28 KiB) Viewed 5604 times
Screenshot 2022-02-10 163855.png
Screenshot 2022-02-10 163855.png (144.82 KiB) Viewed 5604 times
All the best
Nigel
VK6CPU

Anan 8000 DLE, Thetis v2.9.0.8, Protocol 2 V2 1.18
INTEL i9 12900 64.0 GB Ram
User avatar
kc2rgw
Posts: 165
Joined: Mon Jun 22, 2020 5:44 pm

Re: Identifying strange panadapter waveform

Postby kc2rgw » Sun Oct 09, 2022 11:26 am

w9mdb wrote:And what makes you say it's VAC instability?
Not sure that would explain why resetting audio in Thetis fixes it (other than recreating the audio device to VAC).
VBAudio is used by audio professionals with multiple tracks without any such problems.


FWIW the same instability happens with my Sun SDR and also with the USB audio path to/from my TS-590sg. All are connected to Voicemeeter.

I have no firm explanation. When a "client" device "joins the VAC bus" sometimes it doesn't seem to negotiate properly, requiring the client software, SDR or other to restart to re-attach. Generally once it's running, it is stable for me until I restart the "client" application or the computer sleeps etc.

My routine is to start whatever client app up, put it into monitor mode and test TX and see if it is clean. If it is not, I simply toggle the VAC on and off or the software itself off and restart until it runs clean.

I've experimented with multiple sample rates and buffer sizes and though some combinations are somewhat more stable, none are anywhere near what I would call "solid". They all glitch.
User avatar
w-u-2-o
Posts: 5539
Joined: Fri Mar 10, 2017 1:47 pm

Re: Digi mode audio problems

Postby w-u-2-o » Sun Oct 09, 2022 3:28 pm

All: I edited the title of this topic to make it more descriptive. I will soon move it to either the audio or digi mode sub-forums, but just look for it on "Active Topics", it'll be there!

This is looking more and more like a virtual audio problem of some sort. In other words, it has nothing to do with software or firmware per se, other than things need to be set up properly.

While I've seen such behavior in the past, I have not seen it in a very long time. This morning I tried introducing a number of intentional errors in my setup in order to duplicate the problems some of you are seeing.

First, some notes about my setup:

1. The audio path is as complex as it gets: Voicemeeter Potato is used as a "patch panel", connecting Thetis, Reaper Digital Audio Workstation, and (for my experiments) WSJT-X.

2. Some key points to consider:

- Voicemeeter is set to use my ASIO hardware interface (Presonus Studio 192) as the A1 hardware output at 48KHz. It doesn't have to be ASIO, but if your A1 hardware output isn't set to a device that is running 48KHz you could have problems.

- All Voicemeeter virtual devices that show up in the legacy (old fashioned) Windows Sound Control panel should be set to 48KHz, stereo if available, 16 or 24 bit.

- Thetic VAC buffer size should be matched to the A1 hardware output buffer size as reported by Voicemeeter. Example:

Capture.JPG
Capture.JPG (11.35 KiB) Viewed 5533 times

Remember that DUP OFF shows mathematically what is going into the transmit digital-to-analog converter (DAC), DUP ON shows you the actual RF coming out of the radio as received by RX1 during transmit. Finding them looking the same or similar is a good indication that Thetis/Apache is transmitting a true representation of the audio that coming out of the internal, Thetis-side of the Thetis VAC interface. I.e. the problem is with Thetis VAC being properly configured to handle the audio data stream presented to it by Voicemeeter (or whatever you are using for virtual audio connection software, but my discussion will remain Voicemeeter-centric).

I tried a number of things to reproduce the horrifyingly bad transmit spectra that others have posted as examples. Mismatched sample rates in the Windows Sound Control Panel didn't do it: Voicemeeter is just too good at resampling things as required. Mismatched levels (too high, too low) didn't cause bad spectra. Thetis VAC "force" option on/off made no difference. But making the Thetis VAC buffer size too small instantly caused a very bad transmit spectra.

My Presonus interface is manually set to a buffer size of 512, as anything smaller than that causes audio stability problems on my system. Voicemeeter happily follows that automatically and shows that on it's UI, as already depicted above. In the examples below, you can see the dramatic difference in output spectra when the Thetis VAC buffer size is set to 256 vs. 512. Setting it to something larger than 512 was OK, but less than 512 was an instant train wreck.

Note: the small spurs you see in the correct buffer size case are of no consequence. I normally put the floor of my TX display at -75, and anything less than will not be noticeable over the air even if you are S9+40, but I wanted to look a bit further down into the spectra just to see if anything interesting popped up.

The challenge here is that the Thetis VAC interface is 90% manual setup. Get it wrong and things will be ugly. Get it right and things will be fine. We don't see this on app's like Audacity or Spectrum Lab because they automatically follow the settings promulgated through the Windows audio interfaces, just like Voicemeeter will automatically select the correct buffer sizes for the app's and hardware it is connected to.

When running digi modes definitely use MON when initially setting up. You can plainly hear bad transmitted audio that way.

One other thing to consider: if your audio settings seem inconsistent, changing performance from one app launch or system reboot to another, you may be running on the ragged edge. I found this to be true here. I had been running an audio interface buffer size of 256 and it mostly worked, but every once in a while audio would get ragged. Changing this to 512 made it very reliable.

The test signal for the following examples was generated using the WSJT-X Tune button. WSJT-X was connected to Voicemeeter, as was Thetis and my DAW software. This was a full power shot through a KPA1500 amplifier into a dummy load and that is the actual RF signal coming back in from the amplifier output coupler in DUP mode.

Example with proper buffer size:

CorrectBufferSize.JPG
CorrectBufferSize.JPG (773.39 KiB) Viewed 5533 times


Example with buffer size too small:

TooSmallBufferSize.JPG
TooSmallBufferSize.JPG (859.13 KiB) Viewed 5533 times
User avatar
vk6cpu
Posts: 35
Joined: Tue Jul 16, 2019 4:47 am
Location: Perth, Western Australia

Re: Digi mode audio problems (was: Identifying strange panadapter waveform)

Postby vk6cpu » Sat Oct 15, 2022 2:16 am

Thanks for taking the time to look at this issue. Its very much appreciated.

The digital TX side of my setup is quite simple direct pipe from WSJTX/JTDX to VAC1 & 2 (not via VB Potatoe - which I do use for monitoring output from VAC & Mike audio). I was using Muzychenko VACs : cables 2 & 4 being the input to VAC 1 & 2 respectively.

I've spent a few days testing various things - confirmed correct network settings, audio settings and tried larger buffer sizes. STill the same issue - everything runs OK .. then the "glitch" and the horrendous tx output. I have in the past noted a small jump in the overflows/underflows (as seen in the VAC1/2 tab of thetis setup. But, immediately after the respective VAC looked very stable ie no further under/overflows and all other parameters looked normal. But TX would still have that same horrendous output.

Then I had a Eureka Monent (as opposed to the more common seniors moment) -- I opened up the control panel for Muzychenko's VAC. The overflow counter for the problematic audio cable had "runaway" overflows and was still incrementing - although there was no similar indication of this on the Thetis VAC monitor. Attached screendump shows my Muzychenko settings - I just used default.

Screenshot 2022-10-11 143542.png
Screenshot 2022-10-11 143542.png (155.6 KiB) Viewed 5366 times



So I decided to replace Muzychenko with VBA virtual audio cables. VB A-C.

These were initially very unstable using the default Thetis "Advanced" settings. But reducing the Feedback gain a very stable result.
For the last several days, using VB cables, I have not had any issues,

I don't know or understand the reason why - but it solved my problem. If anyone has any suggestions as to why and whether they successfully run Muzychebko with some optimised settings - Id be very interested to hear.

Just an observation on Scott's spurs. When, I first installed VB cables, I noticed spurs on the test tone from WSJTx which were not there when using Muzychenko. Although, I had set all the endpoints of the cables to 48000 - by chance I noticed on the VB control panel the internal rate of the cable was 44100. Setting this to 48000 - cleared the spurs in my case. Screendump attached of spurs due to 44100 - 4800 mismatch w VB cables.


Screenshot 2022-10-11 143542.png
Screenshot 2022-10-11 143542.png (155.6 KiB) Viewed 5366 times



Screenshot 2022-10-12 130743.png
Screenshot 2022-10-12 130743.png (239.36 KiB) Viewed 5366 times
Attachments
Screenshot 2022-10-12 130700.png
Screenshot 2022-10-12 130700.png (578.59 KiB) Viewed 5366 times
All the best
Nigel
VK6CPU

Anan 8000 DLE, Thetis v2.9.0.8, Protocol 2 V2 1.18
INTEL i9 12900 64.0 GB Ram
User avatar
w-u-2-o
Posts: 5539
Joined: Fri Mar 10, 2017 1:47 pm

Re: Digi mode audio problems (was: Identifying strange panadapter waveform)

Postby w-u-2-o » Sat Oct 15, 2022 1:37 pm

vk6cpu wrote:Thanks for taking the time to look at this issue. Its very much appreciated.

The digital TX side of my setup is quite simple direct pipe from WSJTX/JTDX to VAC1 & 2

But it is NOT a "simple direct pipe". You were using Muzy VAC. So that's not simple! It's exactly the same level of software and audio complexity as using VB Cable or Voicemeeter.

(not via VB Potatoe - which I do use for monitoring output from VAC & Mike audio.

If you are using Voicemeeter Potato for this then you have created a MUCH more complex situation by using VB Cable (or Muzy VAC) in addition to Voicemeeter. More on this below.

Then I had a Eureka Monent (as opposed to the more common seniors moment) -- I opened up the control panel for Muzychenko's VAC. The overflow counter for the problematic audio cable had "runaway" overflows and was still incrementing - although there was no similar indication of this on the Thetis VAC monitor. Attached screendump shows my Muzychenko settings - I just used default.

This properly belongs under the heading of "common sense". Any experienced Muzy VAC user would know to check these counters.

So I decided to replace Muzychenko with VBA virtual audio cables.
...
I don't know or understand the reason why - but it solved my problem. If anyone has any suggestions as to why and whether they successfully run Muzychebko with some optimised settings - Id be very interested to hear.

It would be easy to say "Because VB Audio engineering is superior", but that's probably unfair to Muzychenko. I was a long time user of Muzy VAC when it was the only game in town. Since Victor Burel produced Voicemeeter I quickly gravitated to that because it seemed to require a lot less tweaking and the mixing panel metaphor was easier to use and understand. No more fussing with the Muzy control panel or monitoring app's to see what was going on.

One thing that you might have tried is to set the upper and lower sample rates on all Muzy cables to 48000, thereby preventing them from accidentally selecting an improper range (although that did not appear to happen in your screen shot). Another is to similarly lock them to 16 bits per sample, and lock them to either 1 or 2 channel as required.

Finally, another place things can go wrong with Muzy VAC is to forget to go into the legacy Windows Sound Control Panel and the advanced settings tab for every Muzy device and set them all to 48KHz.

Just an observation on Scott's spurs.

Your spurs look nothing like my spurs. They are not related.

When, I first installed VB cables, I noticed spurs on the test tone from WSJTx which were not there when using Muzychenko. Although, I had set all the endpoints of the cables to 48000 - by chance I noticed on the VB control panel the internal rate of the cable was 44100. Setting this to 48000 - cleared the spurs in my case. Screendump attached of spurs due to 44100 - 4800 mismatch w VB cables.

Not only do you need to do this in the VB control panels for each VB cable, you need to go into the legacy Windows Sound Control panel and do it there as well, just like for Muzy VAC cables, and for all Voicemeeter virtual devices as well. This is very important. Everything needs to be "48KHz clean".

Back to your extremely complex setup: if you are already using Voicemeeter Potato for monitoring, then why add the complexity of VB or Muzy cables in addition to that? It would be SO much simpler to:

- Attach Thetis VAC1 to Voicemeeter virtual channel B1 ("VAIO")
- Attach Thetis VAC2 to Voicemeeter virtual channel B2 ("AUX VAIO")
- Attach digi mode programs to Voicemeeter virtual channel B3 ("VAIO3")

Then just use the "send" buttons in Voicemeeter to route audio to where you want it to go. Want VAC1 RX on B1 to go to WSJT-X on B3? Hit "B3" on the B1 channel. Want WSJT-X TX on B3 to go to VAC2 TX on B2, hit "B2" on the B3 channel. Want to monitor VAC1 RX on B1 on your computer speakers? Hit "A1" on the B1 channel (assumes you did a proper job of assigning hardware output A1 to your speakers, which I'm guessing you did). And so on. Very simple once you get the hang of it.

The only negative thing I'll say about Voicemeeter is that Vincent did a truly terrible job of naming the virtual channels. It can be a bit confusing to get them selected properly in other app's like Thetis or WSJT-X.

I'm going to move this topic out of Thetis and into Digital Audio sometime today.

Return to “Digital ("Virtual") Audio”