Thetis 5.1 RADE Mode: RX Audio Silent on Headphone Output Despite Active Signal Meters

Summary

In Thetis 5.1 with the RADE (Reliable Acoustic Data Engine) FreeDV mode enabled, RX audio does not reach the radio's headphone jack even though decoded signal meters respond correctly to AF gain adjustment. The most likely cause is an audio output device routing misconfiguration specific to the RADE audio pipeline, which can differ from the standard Thetis receiver path. The practical impact is that the operator can decode and report RX activity but cannot monitor received audio.

Root-Cause Analysis

Confirmed evidence:

• RX signal is being received and decoded: RADE meters are active and respond to AF gain changes.
• FreeDV Reporter correctly identifies the station and logs TX events, indicating the RADE DSP pipeline and network integration are functioning.
• VAC1 is disabled, ruling out a virtual audio cable routing conflict on the RX path.
• VST is in bypass for both RX and TX, ruling out a VST plugin intercepting or dropping the audio stream.
• A loopback test also produced no headphone audio, suggesting the fault is in the audio output device assignment rather than a downstream hardware issue.
• An error log was generated on application exit, but its content was not included in this report — this is a critical missing piece of evidence.

Reasonable inference:

• RADE in Thetis uses a separate audio rendering pipeline from the conventional AM/SSB/FM RX path. The RX output device for RADE audio may not be automatically inherited from the main receiver audio settings and may require an independent assignment in the FreeDV or RADE configuration panel.
• The signal meter activity confirms that audio samples are being produced internally; they are simply not being routed to the physical headphone output device.
• A sample rate mismatch between the RADE output (commonly 8 kHz internally, resampled before output) and the selected audio device could cause silent output without an obvious visible error in all driver configurations.

Assumptions (unconfirmed without the error log):

• The error log may contain an audio device initialization failure, an unsupported sample rate error, or a buffer underrun warning that would pinpoint the exact failure.
• The headphone jack device may not be selected as the RX audio output device within the RADE/FreeDV audio routing tab specifically.

Alternative causes:

• The Windows audio exclusive mode on the output device could be blocking Thetis from opening the device if another application holds it.
• The audio output volume within the RADE-specific panel (distinct from the main AF gain) may be set to zero or muted.
• A driver-level issue with the radio's USB audio device on this specific OS/driver combination may prevent RADE's audio thread from opening the device.

> Note: A definitive root cause cannot be confirmed without the contents of ErrorLog.txt. The steps below are ordered from most to least likely based on available evidence.

Resolution Steps

1. Retrieve and inspect the error log. Open ErrorLog.txt and search for lines containing audio, device, sample rate, WASAPI, DirectSound, buffer, or exception. Any device open failure or sample rate rejection will immediately identify the fault.

1. Verify the RADE/FreeDV RX audio output device assignment.

• In Thetis, navigate to Setup → Audio (or the FreeDV/RADE-specific audio tab if present in 5.1).
• Confirm that the output device for RX audio is explicitly set to the radio's headphone jack device — do not rely on a "Default" mapping, as RADE may not inherit the global RX output device.
• Save and restart Thetis after any change.

1. Check the RADE panel audio output volume control.

• Open the RADE meter/control window and verify there is no separate output gain or mute control that is independent of the main AF gain slider. Set it to a moderate level (e.g., 50–75%).

1. Verify sample rate compatibility.

• Open Windows Sound → Playback devices → Properties → Advanced for the radio headphone output device.
• Confirm the device supports 48000 Hz (16-bit or 24-bit). RADE outputs are typically resampled to the device's native rate; if the device is locked to an unsupported rate, the audio thread may silently fail.
• Set the device to 48000 Hz, 16-bit and disable exclusive mode if currently enabled.

1. Check Windows audio exclusive mode contention.

• In the same Advanced tab, uncheck Allow applications to take exclusive control of this device.
• This prevents another application (e.g., a virtual audio router, DAW, or OS audio service) from blocking Thetis's access to the device.

1. Re-run the loopback test after each change to confirm whether audio passes before attempting an on-air test.

1. If the issue persists, temporarily switch the RX output device to the system's default speakers or headphones to determine whether the fault is specific to the radio's audio device or a general RADE routing issue.

CLI Commands

On Windows, enumerate active audio playback devices to confirm the radio headphone device name exactly as Windows exposes it:

# List all active audio playback endpoints (PowerShell)
Get-AudioDevice -List | Where-Object { $_.Type -eq 'Playback' }

> Note: Get-AudioDevice requires the AudioDeviceCmdlets module. If unavailable, use the alternative below.

# Alternative: enumerate via WMI
Get-WmiObject Win32_SoundDevice | Select-Object Name, Status, DeviceID

To check for device sample rate and exclusive mode locks via the Windows registry (read-only, non-destructive):

# Check audio endpoint properties (read-only)
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Render\*\Properties" `
  -ErrorAction SilentlyContinue | Select-Object PSPath, *

Configuration Snippets

Thetis audio device configuration is GUI-driven, but the relevant settings to confirm or correct in Setup → Audio are:

# Conceptual representation of the fields to verify in Thetis Setup → Audio

[RX Audio Output]
Device       = <RADIO_HEADPHONE_DEVICE_NAME>   ; Must match exact Windows device name
Sample Rate  = 48000                            ; Confirm device supports this rate
Buffer Size  = 1024                             ; Reduce if underruns appear in log

[FreeDV / RADE Audio]
RX Output Device = <RADIO_HEADPHONE_DEVICE_NAME>  ; Set independently if separate from main RX
Output Gain      = <non-zero value>               ; Confirm not zeroed or muted

Verification

After applying the fix:

1. Open the RADE meter window. Tune to a known RADE/FreeDV signal or use the loopback test.
2. Expected result: AF gain adjustment changes both the meter reading and the audible volume on the headphone jack. Audio should be heard with SNR > 0 dB on the RADE meters.
3. FreeDV Reporter check: Continued correct RX/TX reporting confirms the FreeDV stack remains healthy after any audio device changes.
4. Error log check: Restart Thetis, operate for several minutes, exit cleanly, and reopen ErrorLog.txt. Verify no new audio device or sample rate errors are present.

Rollback indicator: If audio device changes cause degraded TX behavior or other audio paths to fail, revert the device assignment to its previous value in Setup → Audio and restart Thetis.

Prevention

• Always inspect the error log on first launch of a new mode. Thetis generates log entries for audio device failures that may not surface as visible popups during normal operation.
• Document exact Windows audio device names used for each audio path (RX out, TX in, VAC) before upgrading Thetis versions, as device assignments can reset or fail to migrate across major releases.
• Pin sample rates. Lock the radio's USB audio device to a fixed rate in Windows Sound settings to prevent the OS from renegotiating the rate when Thetis opens the device.
• Subscribe to release notes for RADE-specific audio routing changes. RADE is an actively developed subsystem; audio pipeline architecture may change between minor versions.
• Test new modes in loopback before on-air use. A passing loopback test that produces audible output is a reliable gate before live operation.
• Monitor ErrorLog.txt after each session when testing new features; automated log parsing or a script that alerts on ERROR or EXCEPTION entries can catch silent failures earlier.