Unintended PTT keying via system sounds in QTH.app v1.0.3 (build 15) on macOS Sequoia 15.6.1

[Derek Caiden]

Hi, 

I’m running QTH.app v1.0.3 (build 15) on macOS Sequoia 15.6.1, using a Signalink USB interface connected to my transceiver (FTM-510D). The app is working well overall, but I’ve noticed an issue related to audio routing:

Whenever a new station appears on the QTH map, the app plays a “beep” sound — but this sound is sent to the same audio device (USB Audio CODEC) used by the Signalink. The result is that each map update keys the rig momentarily, even when no packet is being transmitted.

To isolate this, I verified that:

• The behaviour stops when QTH.app is closed.

• It resumes as soon as the app plays a map notification sound.

• Routing macOS system audio to a virtual device (BlackHole) prevents the issue entirely, confirming the cause is the system/UI sound output path.

It seems QTH.app’s alert sound output is not isolated from the modem audio output. Would it be possible to either:

1. Disable map notification sounds, or

2. Add an option to route user-interface sounds separately from the TNC audio output device?

This would prevent unintended PTT activation when using USB sound interfaces like the Signalink.

Many thanks for your excellent work on the app — it’s a joy to use otherwise!

Best regards,
Del (MI0WST)

[Weston Bustraan]

Hi Del,

When using the Signalink USB, what is the system audio output set to? i.e. if another app generates an alert sound, where does it go? You said that routing the system audio to BlackHole prevents it from playing; that would seem to indicate that system sounds are being sent to the Signalink.

In general, the preferred setup would be to leave the macOS system audio playing out the system speakers and only choose the Signalink USB device for the Audio Modem. All APRS traffic would then go to the Signalink and all other sounds would go to the default system output. It's been a couple years, but I'm fairly confident that I specifically tested that these 2 audio paths were separate.

With the default configuration, (unless there is a bug) I don't believe QTH.app is configured to make sounds when a station appears. There is a pre-defined config for a "New Station" alert, but it is not enabled by default. Perhaps you enabled it at some point? To find it, go into Settings > Alerts and select "New Station". Uncheck the checkbox if it's enabled.

- Wes W8WJB

--
You received this message because you are subscribed to the Google Groups "qthapp-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qthapp-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/qthapp-users/3c651501-19fb-4514-8d04-4c4d59e9d1cfn%40googlegroups.com.

[Derek Caiden]

Hi Wes,

Thanks for your quick reply — and for clarifying how the audio paths should behave.

To answer your question:
When I’m using the Signalink USB, the system audio output is set to “USB Audio CODEC”, since that’s the device QTH.app uses for the Audio Modem. If I leave it like that, any system sound (for example, a map update or notification) causes the Signalink to key the rig.

If I change the macOS system output to BlackHole 2ch, the unwanted keying stops completely — which strongly suggests that system sounds are indeed being sent to the same audio device used by the modem.

I just re-checked the Settings → Alerts section, and “New Station” was actually unchecked, so it doesn’t appear that any intentional alert was active. The rig still keyed once per new station appearing on the map until I rerouted system audio.

So it may be that macOS is mixing system UI sounds or app-level audio notifications with QTH.app’s modem output device — perhaps an OS-level regression or behaviour change since your last test a few years ago.

Thanks again for looking into this — happy to test any changes or diagnostics you’d like me to try.

Best regards,
Del (MI0WST)

[Weston Bustraan]

Del, 

You shouldn't need to set the system audio to "USB Audio CODEC" (Signalink). I believe that is the root problem. QTH doesn't need the system audio to be changed to the radio audio; it opens whatever device you select.

Try setting it up this way:

1. In System Settings > Sound > Output, use "MacBook Pro Speakers" (or whatever your built-in audio output is)

2. In QTH.app > Connections > Audio Modem settings > Audio Output, choose "USB Audio CODEC" here

- Wes W8WJB

--
You received this message because you are subscribed to the Google Groups "qthapp-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qthapp-users...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/qthapp-users/aafb39d5-8aeb-4385-9723-c81d15ebef91n%40googlegroups.com.

[Derek Caiden]

Hi Wes,

Thanks for the clarification — I followed your setup exactly:

• System Settings → Sound → Output: Internal Speakers

• QTH.app → Connections → Audio Modem → Output: USB Audio CODEC

Unfortunately, in that configuration the rig doesn’t key at all. The only way QTH.app will key the Signalink is if I also set the macOS system output to USB Audio CODEC.

That suggests macOS isn’t actually letting QTH.app open the USB Audio CODEC device exclusively — it seems to rely on the system output being pointed at the same device. Once I switch macOS output back to Internal Speakers, PTT no longer triggers.

Just to confirm, transmit and beaconing work perfectly once the system output is set to USB Audio CODEC, but that’s also when system sounds start keying the rig again.

Happy to help test further or provide logs if that helps narrow down whether this is a macOS device-sharing behaviour change (I’m on macOS Sequoia 15.6.1) or something within QTH’s audio session handling.

Best regards,
Del (MI0WST)