Using latest v2.12.1 of the Swift SDK. I’m having a sporadic problem with reconnects: the session comes back but the agent audio stream played back comes back with degraded with audio quality (sounds like a lower quality audio stream, like what I get via bluetooth in a car). Sometimes reconnects are fine, sometimes they’re degraded. Ending the call and restarting the call is not a problem.
I have not been able to do anything to recover. No difference between “quick” reconnects or “full” reconnects (I set reconnectAttempts in ConnectionOptions to force the reconnect attempt to “full”).
Steps to reproduce: use the Network Link Conditioner to 100% disrupt connectivity in the middle of the call. Watch the app go into reconnecting mode. Unblock network and watch the app come back. The restored audio stream is sometimes corrupt (2-4 out of 10 times).
From the SDK and media docs, reconnects don’t intentionally downgrade audio quality. However, WebRTC can renegotiate codecs and parameters during a full ICE restart, and the playback stack on iOS may resample depending on the active AVAudioSession configuration. In the hi‑fi audio section, LiveKit notes that “the listener’s playback stack may resample the audio, so actual playback quality may be lower than published quality” (/transport/media/advanced/).
Given you’re using CallKit with isAutomaticConfigurationEnabled = false and .playAndRecord / .voiceChat / 48kHz, this strongly points to the AVAudioSession route/mode changing during reconnect and coming back in a lower-bandwidth voice profile (similar to Bluetooth SCO).
A few focused checks:
After reconnect, log AVAudioSession.sharedInstance().sampleRate, currentRoute, and mode to see if they changed.
Confirm the remote track’s codec and params before vs after reconnect.
Try explicitly reapplying your AVAudioSession configuration in room(_:didUpdate connectionState:) when transitioning back to .connected_
What is the sample rate or route changes after a “bad” reconnect. That may help narrow down the issue.