External analog module

Question

Created 1h

Replies 1

Boosts 0

Participants 2

This post is from the WWDC26 LiveCommunicationKit and Push-To-Talk Q&A.

Subject: Technical Inquiry: Interfacing the Push to Talk Framework with External RF Hardware Modules (CB / Amateur Radio Bands)

Dear Apple Engineering Team,

We are writing to inquire about the architectural flexibility of the Push to Talk (PTT) framework when integrating iOS and iPadOS devices with external, custom RF hardware accessories. Uart.

We are developing a specialized communication system that uses an external transceiver module connected via a secure, wired MFi USB-C connection. Our objective is to utilize the native system UI elements provided by the PTT framework (such as the Lock Screen controls and Dynamic Island overlays) to manage transmissions that are broadcast and received over external analog frequencies—specifically Citizens Band (CB) or licensed Amateur (Ham) Radio bands—rather than a standard cellular IP network.

Could you please provide guidance on the following framework capabilities and integration boundaries:

1 Routing Audio to External Hardware Pipelines: Can a ⁠PTChannelManager⁠ instance be configured to pipe its outbound audio buffer stream directly to an external USB-C Core Audio accessory for RF modulation, rather than routing it through an internet-bound network socket?

2 Mapping Hardware Interrupts to ⁠PTChannelTransmitRequestSource⁠: When a user presses a physical push-to-talk button on an external microphone or module connected via USB-C, what is the recommended method to map that hardware interrupt so it registers natively as a system-level transmission request?

3 Handling Unsynchronized Incoming Signals: Traditional VoIP PTT apps rely on an incoming Apple Push Notification (APNs) token to wake the app via ⁠PTPushResult⁠ when someone speaks. In an air-gapped RF environment where an external hardware squelch breaks on an analog frequency, how can the external module signal the iOS device to instantly wake the background thread and initialize a receiving audio session without an internet connection?

4 Compliance and Metadata Constraints: Are there any restrictions within the ⁠PTChannelDescriptor⁠ or ⁠PTParticipant⁠ metadata structures that would prevent us from displaying analog channel frequencies, squelch codes, or Amateur Radio callsigns in place of traditional digital usernames?

Thank you for your guidance on how we can best bridge Apple’s modern PTT framework with external radio hardware ecosystems.

Best regards, Ken Zakreski co Founder, lead developer

Answer 1

DTS Engineer OP

Apple

23m

1 Routing Audio to External Hardware Pipelines: Can a ⁠PTChannelManager⁠ instance be configured to pipe its outbound audio buffer stream directly to an external USB-C Core Audio accessory for RF modulation, rather than routing it through an internet-bound network socket?

I think you've misunderstood how the PushToTalk framework actually works. Similar to CallKit, the PushToTalk framework is primarily an "interface" framework, not a full-fledged PushToTalk implementation. It's connected to the audio system in a few specific ways (like session activation and remote events), but it doesn't actually implement the process of capturing/processing audio or network transmission.

So, yes, what you're describing is possible, but that's because your app was ALREADY responsible for doing all of that.

2 Mapping Hardware Interrupts to ⁠PTChannelTransmitRequestSource⁠: When a user presses a physical push-to-talk button on an external microphone or module connected via USB-C, what is the recommended method to map that hardware interrupt so it registers natively as a system-level transmission request?

This isn't really supported over USB as such, at least not in a general way. First as background, take a look at this post as general background on how transmission activation happens.

Shifting over the USB, the problem here is that the only API which can directly access USB hardware is the ExternalAccessory framework, and that only supports MFi accessories. That's why option 2 in the post I mentioned above only works with Bluetooth. Theoretically, you could create a MFi licensed wired PTT controller, which could then be made to work with #2 as well. However, the work required would be quite substantial and, as far as I'm aware, no one has actually implemented this approach.

Now, option #3 (using "setAccessoryButtonEventsEnabled(...)") DOES work over USB (it's how our USB earbuds work), but that support is specifically tied to hardware that happens to be sending the right USB commands, which the system then recognizes.

3 Handling Unsynchronized Incoming Signals: Traditional VoIP PTT apps rely on an incoming Apple Push Notification (APNs) token to wake the app via ⁠PTPushResult⁠ when someone speaks. In an air-gapped RF environment where an external hardware squelch breaks on an analog frequency, how can the external module signal the iOS device to instantly wake the background thread and initialize a receiving audio session without an internet connection?

Local push connectivity is our standard solution for isolated networks; however, that would require your external hardware to implement its own IP stack to communicate with the iOS device. Note that we did add Ethernet support last year, so you could use that instead of needing the extra complexity of a WiFi network.

4 Compliance and Metadata Constraints: Are there any restrictions within the ⁠PTChannelDescriptor⁠ or ⁠PTParticipant⁠ metadata structures that would prevent us from displaying analog channel frequencies, squelch codes, or Amateur Radio callsigns in place of traditional digital usernames?

Not as far as the system is concerned. It's just displaying the string you gave it and doesn't really care what the contents of the string are.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware