iOS: first remote audio is silent in joined receive-only state until local microphone transmit starts audio engine

[aaron-olds-govcio]

Describe the bug
When an iOS client joins a LiveKit room in a receive-only push-to-talk configuration, the first remote audio does not play while the iOS client is idle.

From the app’s perspective, signaling and subscription appear to work correctly:

• the iOS app shows the remote speaker as active
• the remote audio publication callback fires
• the remote audio subscription callback fires

However, no audio is heard until the iOS client starts local transmit. Once local transmit starts, the previously delayed Android speech becomes audible.

This appears to be a remote playout activation issue in a joined receive-only state.

SDK Version
LiveKit Swift SDK 2.15.2

LiveKit Swift package revision: 77b5aad07909e23adf97d39f205ef7e18e2ceff5

WebRTC XCFramework version: 144.7559.11

iOS/macOS Version
iOS 26.5.2

Xcode Version
Xcode 26.6

Swift 6.3.3

Steps to Reproduce

1. Join the same LiveKit room from Android and iOS.
2. On iOS, connect with autoSubscribe: true and enableMicrophone: false.
3. Keep the iOS client joined but idle. Do not press PTT on iOS.
4. On Android, press PTT and speak.
5. Observe that the iOS client receives active-speaker updates and appears subscribed to the remote audio track.
6. Observe that iOS does not play the live remote audio.
7. On iOS, start local transmit.
8. Observe that once local transmit starts, the previously delayed Android speech becomes audible.

Examples
The problem is reproducible with:

• client-example-swift
• client-example-collection-swift

We have not yet reproduced this in the sample apps. We currently reproduce it in our production app integration.

Expected behavior
Remote audio should begin playing immediately when a subscribed remote participant speaks, even if the iOS client is joined in a receive-only state and has not activated its local microphone.

Screenshots
Not applicable.

Logs
We added app-side instrumentation around room connect lifecycle, remote audio publication/subscription, audio engine lifecycle, audio session snapshots, and first remote PCM frame delivery.

Observed sequence from repeated repros:

1. Room connect succeeds.
2. iOS remains joined and idle in receive-only mode.
3. Android transmits.
4. iOS receives active-speaker updates.
5. iOS logs remote audio publication.
6. iOS logs remote audio subscription.
7. Audio session snapshots during the idle listener state show engineRunning=false.
8. No engine-start callback fires for remote-only playout.
9. No remote PCM frames are rendered during the initial Android transmission.
10. When iOS starts local transmit, engine start callbacks fire.
11. After local transmit begins, remote PCM frames start rendering and the previously delayed Android speech becomes audible.

Relevant app behavior on join:

try await AudioManager.shared.setRecordingAlwaysPreparedMode(false)

try await room.connect(
    url: url,
    token: token,
    connectOptions: ConnectOptions(autoSubscribe: true, enableMicrophone: false)
)

Relevant receive-only listener configuration:

private func configureReceiveOnlyAudio() {
    let session = AVAudioSession.sharedInstance()
    do {
        if session.category == .playAndRecord || session.mode == .voiceChat {
            try session.setActive(false)
        }
        try session.setCategory(
            .playback,
            mode: .default,
            options: [.mixWithOthers]
        )
        try session.setActive(true)
    } catch {
        logger.error("Failed to configure receive-only audio: \(String(describing: error))")
    }
}

Relevant transmit-path engine configuration:

private func configureTransmittingEngineAvailability() {
    do {
        AudioManager.shared.isVoiceProcessingBypassed = false
        try AudioManager.shared.setEngineAvailability(.default)
    } catch {
        logger.error("Failed to configure transmitting engine availability: \(String(describing: error))")
    }
}

Exact instrumentation strings used in the app:

LiveKit remote audio published for <channel>: sid=<sid>, source=<source>, subscribed=<bool>

LiveKit remote audio subscribed for <channel>: sid=<sid>, source=<source>

LiveKit audio session snapshot [connect-post-room]: category=<category>, mode=<mode>, otherAudioPlaying=<bool>, outputVolume=<float>, outputs=<outputs>, inputs=<inputs>, engineRunning=false

LiveKit audio session snapshot [remote-audio-published-<channel>-<sid>]: category=<category>, mode=<mode>, otherAudioPlaying=<bool>, outputVolume=<float>, outputs=<outputs>, inputs=<inputs>, engineRunning=false

LiveKit audio session snapshot [remote-audio-subscribed-<channel>-<sid>]: category=<category>, mode=<mode>, otherAudioPlaying=<bool>, outputVolume=<float>, outputs=<outputs>, inputs=<inputs>, engineRunning=false

LiveKit engineWillStart: playout=<bool>, recording=<bool>, running=<bool>

LiveKit remote audio first frame for <channel>: sid=<sid>, sampleRate=<sampleRate>, frameLength=<frameLength>, channels=<channels>

This suggests the issue is not signaling or subscription failure, but remote playout activation in a joined receive-only state.

Important integration constraints for this use case:

• this is push-to-talk, not a full-time bidirectional call
• joined-but-idle listeners must remain in playback/media semantics
• we do not want to keep the client in permanent .playAndRecord just to make remote audio start
• we do not pre-create or pre-publish the local microphone on join

[aaron-olds-govcio]

// pseudocode inside SDK remote track lifecycle

onRemoteAudioTrackBecameActiveOrSubscribed {
if remotePlayoutDemandCount == 0 {
try? AudioManager.shared.startAudioPlayout()
}
remotePlayoutDemandCount += 1
}

onRemoteAudioTrackNoLongerNeedsPlayout {
remotePlayoutDemandCount = max(0, remotePlayoutDemandCount - 1)
if remotePlayoutDemandCount == 0 {
try? AudioManager.shared.stopAudioPlayout()
}
}

[pblazej]

engineRunning=false with no engine-start callback means playout was requested but the engine enable was suppressed or rolled back before it started. Two things on the app side produce exactly that signature, and both clear the moment local transmit starts:

1. setEngineAvailability(.none) on the receive-only path. .none sets isOutputAvailable: false, which disables playout as well as recording — IsOutputEnabled() returns false, so the subscribe-path InitPlayout/StartPlayout are no-ops and the engine is never created. Your transmit path calls .default, which flips it back. That .none / .default pairing comes from our CallKit example, where it's scoped to the didActivate ~ didDeactivate window; for a PTT flow where idle listeners still need remote audio, output has to stay available and you gate input only.

2. The AVAudioSession not being active at subscribe time. If AudioManager.shared.audioSession.isAutomaticConfigurationEnabled is false and configureReceiveOnlyAudio() runs late — or its setActive(true) throws into that catch — the output node reports a zero sample rate and the engine enable rolls back.

Could you attach rtc logs from the idle-listener repro?

LiveKitSDK.setLogger(OSLogger(minLevel: .info, rtc: true))

That gives the AudioEngineDevice state transitions around subscribe and shows directly which of the two it was — it prints SetEngineAvailability: <in> <out>, the pre-enable category check, and the rollback error code.

One note on configureReceiveOnlyAudio(): if isAutomaticConfigurationEnabled is still true (the default), the SDK already configures .playback whenever only playout is enabled, so that function is duplicating it — and the setActive(false) in there can deactivate a session the engine is still using right after a PTT release.

[aaron-olds-govcio]

We are seeing an iOS receive-only PTT issue where remote speech from Android is not audible on the first transmission until the iOS client activates its own microphone once.

Integration model:

• On startup, the iOS client auto-joins one default/master PTT channel in receive-only mode.
• The app can also dynamically create and join additional LiveKit/PTT channels later.
• Joined-but-idle listeners are intended to remain receive-only until the user actively presses PTT.

Current behavior:

• iOS joins with auto-subscribe enabled and microphone disabled on join.
• iOS receives remote participant presence, active-speaker updates, and remote-audio subscription callbacks successfully.
• While iOS remains an idle listener, Android speech is not heard.
• As soon as iOS starts local transmit once, the audio engine starts and the previously missing remote audio becomes audible.

Observed signature from logs:

• Remote publish/subscription succeeds.
• Active-speaker UI updates succeed.
• engineRunning=false remains true in the idle-listener repro until iOS activates its microphone.
• No engine-start callback occurs for remote-only playout before first local transmit.
• First remote PCM/audio render appears only after local transmit starts.

What we already ruled out on the app side:

• No current use of setEngineAvailability(.none) on the receive-only path.
• AudioManager.shared.audioSession.isAutomaticConfigurationEnabled is enabled.
• The old manual receive-only AVAudioSession reconfiguration path has been removed.
• Join uses autoSubscribe=true and enableMicrophone=false.
• The issue did not change after testing:
  • disabling default/master-channel auto-connect and then manually joining
  • delaying initial auto-connect
  • limiting startup to one subscribed/listening channel
  • moving channel fetch/connect timing later in startup
  • changing auto-connect scheduling behavior

Minimal repro:

1. Join the same PTT/LiveKit room from Android and iOS.
2. On iOS, connect with autoSubscribe=true and enableMicrophone=false.
3. Leave iOS in joined receive-only state and do not press PTT.
4. Press PTT on Android and speak.
5. Observe that iOS shows active-speaker / remote subscription activity but no audible audio.
6. Press PTT on iOS once.
7. Observe that the iOS audio engine starts and Android audio becomes audible.

Question:
Can you review whether remote-only subscribed audio on iOS is expected to start playout and engine activation in this joined receive-only state without any prior local microphone activation, or whether there is an SDK bug/regression in the initial playout path?

[bennnjamin]

We have the same issue. It's pretty significant for us because we have some users who may never publish to a room and only subscribe.

[hiroshihorie]

Hi, looking into this one today. 🙏

[bennnjamin]

FYI calling AudioManager.shared.setRecordingAlwaysPreparedMode(true) before joining the room seems to fix it for me but that might not always align with more esoteric Audio routing configurations

[hiroshihorie]

I tested receive-only with the swift-example app and remote audio plays immediately, so the default playout path works and this needs a specific condition to reproduce.

Are you using Apple's PushToTalk framework (PTChannelManager) or CallKit, or is this a custom PTT UX?

[aaron-olds-govcio]

Thanks. This is a custom PTT UX built on LiveKit, not PTChannelManager and not CallKit.

In the current integration, the app joins in a receive-only state with auto-subscribe enabled and the microphone disabled on join. LiveKit automatic AVAudioSession configuration remains enabled, and we only enable/publish the mic during an actual PTT press. So there is no prior PTChannelManager or CallKit activation step that should be required for first remote playout.

We did also investigate whether multi-channel subscription was part of the issue, since our production app can join a default/master PTT channel plus additional channels and iOS audio ownership is process-global. That said, we were still able to reproduce the same “no remote audio until first local transmit” behavior after simplifying the flow down to a single joined receive-only listening channel. So multiple channels may be an exacerbating factor in our production setup, but they do not appear to be the sole condition required for repro.

From our perspective, this reproduces in a custom LiveKit receive-only listener flow where subscribed remote audio is expected to start playing before the local user has ever transmitted.

One additional data point: calling AudioManager.shared.setRecordingAlwaysPreparedMode(true) before join does appear to mask the issue for us. We are hesitant to rely on that as a long-term fix, though, because this is a push-to-talk app and our idle listeners are intended to remain in playback/media semantics rather than be kept pre-prepared for recording.