drowe67
[Software Issue] Virtual Audio Cable (VAC) Parameters
Platform
Windows
Platform Version
Win10
FreeDV Version
e56e
Steps to Reproduce
Start FreeDV and press PTT
Expected Behavior
Audio from microphone without glitch on other stations receiving FreeDV audio
Actual Behavior
Audio from microphone (reported from others) is with occasional glitches even when they report strong signal eg with 20+dB SNR, glitches appear every about 30sec, sometimes more often. the glitches apear by increasing the Resyncs number.
Additional Comments
Current setup here is using PowerSDR and Virtual Audio Cable (VAC) v4.60 on a SDR1K. It seems the audio from FreeDV to PowerSDR, the transmitted audio has some issues occasionally. Receiving cable, from PowerSDR to FreeDV, looks just fine as it give a proper audio without glitches on receive/listening other stations. Are there any recommended settings for Muzychenko's VAC for the cables used ? Specially for the cable used for Tx?
Are you using Ethernet to connect to the radio, or is the connection over something like Wi-Fi? The latter tends to drop packets fairly often, at least with my Hermes Lite.
Also, do you see this problem with, say, VB-Cable, or just VAC?
Hi, yes, connection to radio is via Ethernet and it does not show any dropped eth packages. Do not have tested the VB-Cable, only VAC, have it way too many years now ~15 and never had any issues in digimodes.
It is shown that in the Windows build action, there is a stage where tests are conducted with the use of both VB-Cable and VAC. As described above, I use the VAC for the Radio to FreeDV cables, whereas in the tests VAC is used for Mic/Spk to FreeDV. Is it possible in your build action tests to switch them so VAC to be used for Radio to FreeDV and see what happens? Also, can you please let me know the settings used for those cables (both VB-Audio and VAC).
The used VAC settings in my setup are all the same as this
It is shown that in the Windows build action, there is a stage where tests are conducted with the use of both VB-Cable and VAC. As described above, I use the VAC for the Radio to FreeDV cables, whereas in the tests VAC is used for Mic/Spk to FreeDV. Is it possible in your build action tests to switch them so VAC to be used for Radio to FreeDV and see what happens? Also, can you please let me know the settings used for those cables (both VB-Audio and VAC).
The GH actions actually rely on VB-Cable's loopback behavior to be able to execute as FreeDV runs in full duplex mode. Not sure if that's possible with VAC, at least in a way that doesn't require user input.
Re: settings--they should be the defaults that come with VAC/VB-Cable.
Hi, yes, connection to radio is via Ethernet and it does not show any dropped eth packages.
Any way you can set up a second radio as RX to rule out any issues with propagation/QRM/etc. on the other end?
Been doing some testing on several cases.
Also, do you see this problem with, say, VB-Cable, or just VAC?
Acquired also VB-Cable and did test the setup with all cables via VB-Cable. Result is the same having the glitches and "Resyncs".
The GH actions actually rely on VB-Cable's loopback behavior to be able to execute as FreeDV runs in full duplex mode. Not sure if that's possible with VAC, at least in a way that doesn't require user input.
Used the "full duplex mode" connecting FreeDV's "Input To Computer From Radio" in the same cable as "Output From Computer To Radio", thus having a loop. Did this test twice, first with VB-Cable and then VAC. In both tests there were the same results, still having the glitches and "Resyncs".
Any way you can set up a second radio as RX to rule out any issues with propagation/QRM/etc. on the other end?
Did a second rig setup in the shack, a second radio side by side with the first, one transmitting and the second receiving. Did this twice, one with VB-Cable and then with VAC. In both tests still having the glitches and "Resyncs" heard on the receiving end.
In all the tests via VAC, the VAC control panel was used to verify if there is any overflow or underflow of packets. None was indicated there. Also tested the system with LatencyMon (https://www.resplendence.com/latencymon) and it was showing no issues.
As said, the receive part when using virtual cables, is just fine, no glitches/overflows/underflows or any issue at all, uninterruptible operation there.
So, I did a final test.
It is a 'hybrid' setup. The receive part still continues to have virtual audio cable but the transmitting part was through real hardware audio ports. It happens my system to have some more hardware audio ports, so I used them and connected a real cable between them FreeDV "Output From Computer To Radio"->HDMI LG Monitor Audio Output->PHYSICAL CABLE->PC Line Audio Input->PowerSDR Audio Input.
That test did not produce any glitches or Resyncs on the receiving station!
So these tests & results show that any virtual cable used in receive part of FreeDV works just fine. Any virtual audio cable used in the transmit part of FreeDV has glitches. When actual audio hardware is used in the transmit part of FreeDV works just fine.
At least this is the result when conducted the tests in my own shack and the systems that are here.
IMHO, an interpretation is that something happens specifically in the FreeDV Tx output to a virtual cable, the interface between those two parts is not behaving correctly. Could this be a timing/clock issue, a master/slave issue or something weird of course I cannot tell but this is a strong candidate point that needs attention.
Can you send a screenshot of your audio options in FreeDV when using VAC for TX? I noticed that your VAC settings show a sample rate range between 8 kHz and 192 kHz so I'm curious to know what Windows thinks the "native" rate is.
Might also be worth forcing the sample rate range in VAC options to be something like 48 kHz to 48 kHz in case it's something related to resampling within the application.
Can you send a screenshot of your audio options in FreeDV when using VAC for TX?
This is the FreeDV audio options screen, all required interfaces are handled at 48KHz
I noticed that your VAC settings show a sample rate range between 8 kHz and 192 kHz so I'm curious to know what Windows thinks the "native" rate is.
Might also be worth forcing the sample rate range in VAC options to be something like 48 kHz to 48 kHz in case it's something related to resampling within the application.
In order to avoid any uncertainty, PowerSDR is always started first and the VAC ports are instantiated at 48KHz, this is the VAC control panel as soon as PowerSDR gets started, it sets the samplerate to 48000
And this is the VAC control panel as soon as FreeDV is started after PowerSDR, see the "Streams" on top left, it changed from 2 to 4 .
All streams work at 48KHz, 16bit.
Forgot this one
The GH actions actually rely on VB-Cable's loopback behavior to be able to execute as FreeDV runs in full duplex mode. Not sure if that's possible with VAC, at least in a way that doesn't require user input.
Of course and VAC can perform the same as VB-Cable without user input. Here is what the "loopback" settings look like when VAC is used
and
The above are simple settings and they create the looback effect, FreeDV out to FreeDV in.
Also the settings used for having this loopback with VB-Cable are
and
As mentioned, everyone can test this and reproduce the problem. Just configure the loopback with either the VB-Cable or VAC (if you have the full version), set the full dublex (uncheck) in Tools->Options->Modem
No need for actual rig or hardware or other rig control SDR software application, simply using just FreeDV and VB-Cable or VAC everyone can test and reproduce the issue mentioned.
The issue is the large number of Resyncs when virtual cable is used in FreeDV Tx, even during loopoback (many per minute), whereas that should have been no resyncs at all since it is a loopback..!!
This issue affects many SDR rigs that rely on PC control application, eg FlexRadio, ApacheLabs, SunSDR, HermesLite etc. All these rely on virtual cables in order to have digimodes.
Hello,
i can confirm this, i´m using a Anan 100D and it is temperamental the FreeDV encoding and decoding, one day is working fine the other day i may have to reboot to make it work acceptable.
We only discover that there was also problems on RX because it was several persons at same time, and one get glitches on RX from a station and the other say it was normal.
I notice one detail, signals 9+20 were the SNR drops to zero and rise again, that is were the glitches show up, i have play with Filter sizes and buffers to get better stability, and one friend with a 200D make a simple test, using a laptop for FreeDV and the regular PC for Thetis, is TX SNR rise to 32 most of the times and gets more stable, and with my radio i can only go to 24,, 25, and before it was only 16 dB.
It seams that independent from the strong signal that we arrive to the other radio the connection from FreeDV to Thetis changes the SNR during TX like a fluctuation.
People with radios like FT-DX10 have no problems with a regular PC, and the tx and rx are much more stable than if we use Rade and Thetis on same machine.
One last thing, for me on decoding Linear Phase works better than Low latency on Thetis.
I hope a solution / improvement can be found.
For everyone experiencing this issue--can you go to Tools->Options->Debugging after the dropout occurs and let me know what the FIFO numbers show? (Screenshots of this window are okay.)
Reproducing the issue with the loopback setup, just FreeDV in full dublex and VAC Every few seconds there is a drop in SNR and FIFO numbers rising
More often drops with VB-Cable
I may have missed it in previous comments, but what hardware in your system (i.e. CPU, RAM, etc.)? Any way to try on a faster machine to see if there are any differences?
The first test was with "Cable C".
Next was with "VoiceMeeter Input" VAIO.
Next with "Line 2" (Virtual audio cable)
Return back to "Cable C".
Notice one thing, Cable C on first test have many fails and SNR drops, but on last test it almost didn´t fail, i have close the FreeDV open it again and i start to have glitches and SNR from 34 to 0 at same time.
Make one more test with "Cable C" and again many fails
Next i share 3 videos, on some you can see the Debugging at same time SNR drops and audio came out but i´m not talking, it is like a "delirium" of the software, we don´t talk and it start to "talk" alone.
You can watch online or download it.
https://mega.nz/file/5MclnL5b#y9B34Xe7MG8JzMYou5bAKi_hp8dvqTUVQCuJKCmRGcU https://mega.nz/file/ERUhSJYK#gX3sZsSRgqGqjsyvAsCKdhXEOKEt5QS6C-JWG0faj8s https://mega.nz/file/ccFRmAZb#3dlLSTYpsPTx9WajuOSse6v7m8qYgbOyVp3gWRV2XiI
Short conclusion, on LOOP and in my case the VoiceMeeter was the more stable in any test i did but also have short fails.
8 Core CPU with Hyper-threading
OS
Here is the requested info from my side
CPU 13th Gen Intel(R) Core(TM) i5-13500, 14 cores, 20 threads, 32GBRAM, WIN11 Pro
A small video ~60sec showing the issue, setup is with FreeDV loopback (VB-Cable) in full dublex Pay attention to the frequent SNR drops in top left with accompanying Resyncs
https://mega.nz/file/MSpjCbpS#qh-8SAKX50b_a71RCJbzr3uJk1lO-Bgg7-_v4z1oYBA
And this is the resulting Debug info requested
Same results are with a bit older system CPU Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3408 Mhz, 4 Core(s), 8 Logical Processor(s), 32GBRAM, WIN10 exhibiting the same issue.
@tmiw I'm sure you can test this yourself, in any Windows system you might got there. This is reproducible, just the FreeDV application and the VB-Cable for the loopback. Since this can be so easily reproduced, you can have it tested and examine yourself the application internals during the issue.
@AristarchosOfSamos it was the same at my side, the strange part is a friend using a laptop only for FreeDV and other PC for Thetis and is sound never fails.
Today i have the chance to test only with the Voicemeeter, and i can tell you that i have the most perfect QSO ever with FreeDV, not a single drop on SNR and the audio quality was superb.
In my case on "DSP / Filter Type" i confirm again that i need to use Linear Phase, the Low Latency drops the SNR on RX from 30 to 25 dB or less.
If you have the chance try the VoiceMeeter vac´s, maybe it works also for you at least as a temporary solution waiting for @tmiw to find a final fix.
Just to inform, the other friend using a Laptop for FreeDV and other PC for Thetis change the VAC´s to VoiceMeeter and problem solved, he can run FreeDV on same PC, recording videos at same time and not a single glitch.
The SNR really drops from 32 to 27~28, so i think that there is something with the encoded signal send to the radio that is lowering the SNR.
Imagine, i have seen FreeDV decoding signals with SNR -4 dB, but if the other radio is transmitting already with less 5 dB SNR than with Loopback i will miss that station before than if is SNR was 5dB higher.
@Roturbo Thanks for the tip. though I'll wait for @tmiw proper solution. The one tweak you mention adds more layers as it acts as an intermediate in the current ports either virtual or hardware. Also as you said, it does have an effect on the stream and there is a loss of an additional 4 to 5 dB most likely due to its internal stream/DSP processing. For me, I already use the workaround I mentioned above in https://github.com/drowe67/freedv-gui/issues/837#issuecomment-2687343124 in what I call a 'hybrid' setup whereas the Tx FreeDV path has a real hardware audio connected, with that got no resyncs but it needs an additional hardware audio card. It is a workaround and not an elegant one so I'll wait for the proper solution.
@tmiw Long time applications that use PA for many years now without any issues on virtual audio cables are the OpenHPSDR apps in TAPR, eg Thetis https://github.com/TAPR/OpenHPSDR-Thetis https://github.com/ramdor/Thetis (ApacheLabs fork) or the older PowerSDR https://github.com/TAPR/OpenHPSDR-PowerSDR If you are familiar with them ignore this message, otherwise all the above could give you some hints on how they use PortAudio without issues.
The good news is that I found a bug in the tests run by GitHub, so with that plus a tweak to the test used I think I'm able to consistently duplicate this. You can follow along with the investigation at https://github.com/drowe67/freedv-gui/pull/840 if you'd like.
That said, even if there is a solution found I'd like to use some caution as I also don't really want to break things for people using standard radios/audio devices.
@tmiw Long time applications that use PA for many years now without any issues on virtual audio cables are the OpenHPSDR apps in TAPR, eg Thetis https://github.com/TAPR/OpenHPSDR-Thetis https://github.com/ramdor/Thetis (ApacheLabs fork) or the older PowerSDR https://github.com/TAPR/OpenHPSDR-PowerSDR If you are familiar with them ignore this message, otherwise all the above could give you some hints on how they use PortAudio without issues.
Looking at the Thetis code did point out something I missed while trying to enable exclusive mode, so thanks for that. 👍
Hi @AristarchosOfSamos
The one tweak you mention adds more layers as it acts as an intermediate in the current ports either virtual or hardware.
Not the case, my micro have direct input to FreeDV, and the output goes direct to speakers, the only thing i change was the VAC "C" to receive the audio from Thetis and send to Thetis again, move it to Voicemeeter and all works perfect.
The layers are the same, only the Virtual Audio Cable change.
Also as you said, it does have an effect on the stream and there is a loss of an additional 4 to 5 dB most likely due to its internal stream/DSP processing.
I make some more test today.
On Loopback as you explain to make the test i always have 33~34 dB SNR, and that includes the VAC´s that drops and losing sync, they also go high as 34 dB for some time on loopback before they fall and do a resync.
On normal TX using also VoiceMeeter my signal at the other side have less 6~7dB (27dB), the only thing that change was the loopback removed and audio comes form Thetis and enter in Thetis with same VoiceMeeter (vac).
Maybe this small drop in SNR with strong signals is normal or related to Thetis configuration, or because Thetis is also using PortAudio.
The other friend receiving my signal was able to rise my SNR to 30 dB by closing the AGC to 8 but i have made the same test and no effect at all on his signal that was also about 27dB.
For me, I already use the workaround I mentioned above in https://github.com/drowe67/freedv-gui/issues/837#issuecomment-2687343124
Any virtual audio cable used in the transmit part of FreeDV has glitches.
VAC A-B-C did have problems, VoiceMeeter that is also a vac work normal.
I´m not saying that FreeDV doesn´t have a problem, because it have and i notice it also, but i can say that for me and other person using Thetis the vac "VoiceMeeter" in the transmit part of FreeDV have work without glitches
For me is working like never, but a final solution on the software will be better.
The most recent Windows build in the PR I mentioned seems to be more reliable now if you want to give it a try: https://github.com/drowe67/freedv-gui/actions/runs/13646281198/artifacts/2686402180. Let me know if that improves things at all.
@tmiw
it gives one error.
Not only on Rade,, other modes also have same error.
it gives one error.
Double check the selected sample rate in Tools->Audio Config? On Windows there should only be one option that you can choose.
Good work @tmiw !
Tested with VAC loopback and its just fine now.
I'll test it also at night with real QSOs and I'll close the issue. Really great work on a very difficult task!
@tmiw i have remove and install it again with Admin rights, now it didn´t give me error.
I will test it later and will come here to report.
Tanks
Tested with VAC loopback and its just fine now.
I'll test it also at night with real QSOs and I'll close the issue. Really great work on a very difficult task!
Don't close this yet, actually. I'm still tracking down a possible issue on macOS, plus the proposed changes need to be tested with actual hardware as well (i.e. not VAC/VB-Cable) to make sure nothing broke for those.
@tmiw i have remove and install it again with Admin rights, now it didn´t give me error.
I will test it later and will come here to report.
👍
@tmiw hi
for me uninstall and reinstall as admin solve my error, the other friend have different error see picture, the VAC that have problems still have it, VoiceMeeter is the whiner.
He have restore defaults on FreeDV and no joy, every time he starts the error show up.
We test it,, he was using old version and was using new version dev2, QSO goes normal without glitches.
About the errors after install, lets see if other users have same type of problems.