[BUG] TCI/VAC1 Feed

[Scottay1967]

testing ArtemisSDR with a SunSDR2DX using TCI audio integration together with Decodium/WSJTX FT2/FT4/FT8 software.

Current software chain:

• ArtemisSDR
• Decodium/WSJTX
• TCI Audio
• VAC1
• Log4OM
• Behringer USB Audio CODEC
• Windows WASAPI audio

Observed behaviour:

1. RX1 AF level directly affects Decodium decoding performance.

• If RX1 AF is set very low or muted, Decodium receives insufficient audio and decode performance drops or stops.
• Increasing RX1 AF to around 50% restores normal decoding.

This suggests the TCI/VAC audio stream is being sourced from the post-AF monitor/output bus rather than from a fixed DSP-level digital audio stream.

2. RX audio appears to leak internally into TX/microphone paths.

• Even with microphones physically unplugged, RX audio activity appears on microphone/input meters.
• Increasing RX1 AF increases apparent microphone/input activity.
• This occurs even with headphones disconnected, indicating the issue is not acoustic feedback but internal audio routing.

3. VAC1 appears required for normal phone audio operation.

• Disabling VAC1 removes microphone/headphone operation entirely in my current configuration.
• When Decodium launches, Artemis automatically switches the radio to DIGU and disables VAC1 behaviour, but decoding still depends on RX1 AF level.

4. The routing appears highly coupled internally.
   Current behaviour suggests:
   RX Monitor Audio
   → shared AF/DSP bus
   → VAC/TCI stream
   → possible monitor/record/input paths

rather than:
DSP Fixed-Level Audio
→ isolated TCI/VAC digital stream

and separately:
User RX Monitor AF
→ speakers/headphones only

Why this may be problematic:

For SDR digital operation, decoder applications such as Decodium ideally should receive a fixed-level DSP audio stream independent from:

• speaker volume
• RX monitor AF
• headphone level
• monitor routing

Currently, user monitor AF changes appear to affect:

• decode level
• internal TX/input metering
• monitor routing behaviour

This creates several issues:

• difficult gain staging
• unexpected RX→TX bleed behaviour
• confusing monitor interactions
• inability to independently adjust listening volume and decoder input level
• difficult integration with external audio processing or monitoring software

Suggested architecture improvement:

Ideally the software could expose:

1. Fixed-level DSP digital audio output for:

• TCI audio
• VAC digital modes
• decoder applications

2. Independent monitor/output AF path for:

• speakers
• headphones
• operator listening volume

This would separate:
operator monitor audio
from
digital decode audio transport.

The current architecture appears to couple these buses together internally, which makes behaviour difficult to predict when using TCI + VAC + external digital software simultaneously.

Regards,
Scott
VK4SHG

[kk68]

Hi Scott,

Thanks again for the careful write-up. Your point #1 (RX1 AF level affects Decodium decoding) was reproduced locally with JTDX, root-caused, and fixed in v2.1.3 — released today.

📦 v2.1.3 release: https://github.com/kk68/ArtemisSDR/releases/tag/v2.1.3

What was wrong. Your inference was correct: VAC1 RX and TCI RX audio were both being tapped from the WDSP audio buffer after the AF / volume slider was applied (SetRXAPanelGain1 inside WDSP's RXA pipeline). Same buffer also fed the WAV recorder. So the operator's listening volume was effectively the master input gain for every digital downstream consumer.

What changed. RX AF / volume slider now controls the speaker mixer's per-input gain (SetAAudioMixVol on cmaster's audio mixer 0) instead of WDSP's panel gain. WDSP panel gain is pinned at 1.0. Net effect:

• VAC1, VAC2, TCI RX, and the WAV recorder receive fixed-DSP-level audio independent of the AF slider position. Set AF for what you want to hear; set VAC1 RX Gain (Setup → VAC → RX Gain) for what your decoder hears. They finally do separate things.
• Speaker / headphone path is unchanged in feel — AF slider still controls listening volume the way it always has, just applied at the mixer instead of inside WDSP.
• WAV recordings are now at full DSP level regardless of AF.

Re-tuning note. If you've been running with VAC1 RX Gain set to compensate for AF=50%, your decoder will see roughly 2× the audio level it used to. Lower VAC1 RX Gain by ~6 dB once after upgrading.

On your point #4 (architectural separation between operator monitor audio and digital decode audio transport): that's exactly what v2.1.3 implements. The two paths are now separated at the mixer boundary.

On your point #2 (RX audio appearing on TX/mic meters even with mic unplugged): this is not fixed in v2.1.3 and I want to look at it separately. Two things would help me chase it:

1. With Decodium and any other VAC consumer completely closed, and nothing on the other side of VAC1, do you still see RX activity on the mic/input meters when RX audio is loud? If "no", it's an external loop (Decodium's TX side feeding back through VAC1 TX → Artemis input). If "yes", that's a real internal routing issue I want to track down.
2. Radio firmware version — what firmware is your SunSDR2 DX running? (radio web UI → main page). I track this on every report.

On your point #3 (VAC1 required for normal phone): that suggests your audio is currently going entirely via VAC even for SSB voice. On DX, the more typical Artemis chain is cmASIO (Setup → Audio → cmASIO tab) for the radio I/O and VAC1 only for the digital-mode app feeding. Not a bug, but happy to walk through that separately if you'd like to simplify the chain.

One side effect to flag. The legacy "Mute will mute VAC1" option in Setup is now inert in v2.1.3 — that option used to silence VAC by zeroing the WDSP gain, leveraging the same coupling we've just removed. Users who want VAC silenced should toggle the VAC1 enable directly. May be reworked in a future release if there's demand.

Thanks again — your write-up made the diagnosis fast.

73, Kosta

[RobbiePh]

I've installed V2.1.3, VAC1 is enabled, how do I control the volume? de Ei2iP.

[kk68]

Hi Robbie — and apologies for putting you through this. v2.1.3 shipped a real bug for VAC listeners; you flagged it within hours, and I should have caught the impact on the OpenHPSDR / Thetis-era default workflow before pushing the fix out. v2.1.5 restores AF slider control over VAC1 volume:

📦 https://github.com/kk68/ArtemisSDR/releases/tag/v2.1.5

Mechanism: AF slider now drives both the speaker mixer (v2.1.3 behaviour, kept) AND the VAC mixer's RX input gain (new). WDSP gain stays pinned at 1.0, so TCI users keep the fixed-DSP-level feed Scott asked for in the issue body — best of both. Setup → VAC1 → RX Gain still works as a set-once trim on top.

Scott — your TCI architectural separation is unchanged. The fix lives at the per-VAC-mixer level, downstream of the audio tap that feeds TCI, so TCI clients (Decodium etc.) still see fixed DSP level regardless of AF.

73, Kosta

[Scottay1967]

Thanks Kosta, I’m about an hour away from trialing it. As usual I’ll report anything that may not be working but, it all sounds good so far!Regards,ScottVK4SHGSent from my iPhoneOn 9 May 2026, at 2:14 am, kk68 ***@***.***> wrote:kk68 left a comment (kk68/ArtemisSDR#40) Hi Robbie — and apologies for putting you through this. v2.1.3 shipped a real bug for VAC listeners; you flagged it within hours, and I should have caught the impact on the OpenHPSDR / Thetis-era default workflow before pushing the fix out. v2.1.5 restores AF slider control over VAC1 volume: 📦 https://github.com/kk68/ArtemisSDR/releases/tag/v2.1.5 Mechanism: AF slider now drives both the speaker mixer (v2.1.3 behaviour, kept) AND the VAC mixer's RX input gain (new). WDSP gain stays pinned at 1.0, so TCI users keep the fixed-DSP-level feed Scott asked for in the issue body — best of both. Setup → VAC1 → RX Gain still works as a set-once trim on top. Scott — your TCI architectural separation is unchanged. The fix lives at the per-VAC-mixer level, downstream of the audio tap that feeds TCI, so TCI clients (Decodium etc.) still see fixed DSP level regardless of AF. 73, Kosta —Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.Message ID: ***@***.***>