Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

iOS externalCallSystem: speaker preference maps to AVAudioSession mode videoChat (implicit defaultToSpeaker), so the CallKit Speaker button cannot turn the speaker off

Abierto
  • ¿Algo no está bien?
#1,227 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
dart, flutter, ios
Área
audio-video-rtc, mobile-dev

Línea de trabajo

Start by reading ResolvedAudioSessionPolicy.appleConfiguration and LiveKitPlugin.applyAudioSessionConfiguration, then trace the engine re-apply path through AudioEngineDevice and LKAudioEngineObserver.applyManagedConfiguration. Verify how speaker routing behaves under externalCallSystem when changed from both the app and CallKit. Done means either control can switch between speaker and receiver, and an engine re-apply does not undo the user's route choice.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Describe the bug

On iOS with AudioSessionManagementMode.externalCallSystem, after the app sets AudioManager.instance.setSpeakerOutputPreferred(true), the Speaker button in the system CallKit call UI stays on and can't turn the speaker off. The app can still move audio back to the earpiece with setSpeakerOutputPreferred(false), but the user can't do it from the CallKit UI (lock screen, or the in-call screen reached from the call pill).

This looks like the same symptom as #725, which was closed as not planned on 2.3.6. It still happens on the new AudioManager/externalCallSystem path in 2.13.0.

To Reproduce
  1. Report a call to CallKit and use the documented coordination: setAudioSessionManagementMode(AudioSessionManagementMode.externalCallSystem), and setEngineAvailability gated on provider(_:didActivate:) / didDeactivate.
  2. Connect the room and publish the microphone. The call is on the earpiece (setSpeakerOutputPreferred(false)).
  3. Call AudioManager.instance.setSpeakerOutputPreferred(true). Audio moves to the speaker, and the CallKit UI shows Speaker on.
  4. In the CallKit UI, tap Speaker to turn it off.

Expected: audio moves to the receiver and the button turns off, as in the Phone app and as it does when the call started on the earpiece.

Actual: audio stays on the speaker and the button stays on.

Cause

ResolvedAudioSessionPolicy.appleConfiguration, whose automatic branch is also used for externalCallSystem, expresses the speaker preference as the session mode:

appleAudioMode: preferSpeakerOutput ? AppleAudioMode.videoChat : AppleAudioMode.voiceChat,

Apple's documentation for AVAudioSession.Mode.videoChat:

Setting this mode also causes the system to automatically apply the allowBluetoothHFP and defaultToSpeaker category options.

And for .defaultToSpeaker:

Use it to modify the category's routing behavior so audio is always routed to the speaker rather than the receiver … When using this option, the system doesn't honor user gestures.

The CallKit Speaker button is such a user gesture: it changes the output route override. With defaultToSpeaker in effect (implicitly, via videoChat), the non-speaker choice falls back to the speaker. The app's own setSpeakerOutputPreferred(false) works only because it switches the mode back to voiceChat.

There is a second, related problem. LiveKitPlugin.applyAudioSessionConfiguration calls overrideOutputAudioPort(forceSpeakerOutput ? .speaker : .none) on every re-apply for playAndRecord. Since the #1127 review fix (b70b39b) this also runs under externalCallSystem. AudioEngineDevice re-applies after AVAudioEngineConfigurationChangeNotification (ReconfigureEngine() → OnEngineWillEnable → LKAudioEngineObserver.applyManagedConfiguration). So on a voiceChat session, a speaker route the user picked in the CallKit UI can be reset to .none by the next engine reconfigure. Neither the app nor LiveKit asked for that change.

So under externalCallSystem no configuration lets both the app and the CallKit UI switch between speaker and earpiece:

  • videoChat means the CallKit UI can't leave the speaker.
  • voiceChat plus a system-UI override means the next engine re-apply can wipe the override.
  • force: true adds overrideOutputAudioPort(.speaker) but keeps videoChat.
Suggested fix

Under externalCallSystem, where the system call UI also controls the route:

  • Keep the mode at voiceChat and express the speaker preference as overrideOutputAudioPort(.speaker) / .none. That is the mechanism the CallKit button itself uses, so both stay in sync.
  • Don't reset the output override on engine-lifecycle re-applies. Only change it when the app explicitly changes the speaker preference.

Alternatively, add an opt-out from mode-based speaker routing, so apps can keep voiceChat and handle the override themselves without LiveKit clearing it.

Platform information
  • livekit_client 2.13.0, flutter_webrtc 1.6.2+hotfix.3, WebRTC-SDK 150.7871.01
  • iOS, iPhone. Seen in production on 1:1 calls reported to CallKit (flutter_callkit_incoming); CallKit activates the session, LiveKit is in externalCallSystem.
  • Also affects rooms that start with the speaker preferred, which get videoChat from the first configuration.
Lenguaje dominante
Dart
Estrellas
421
Forks
260
Merge medio
3 d 9 h
PR fusionados (30 d)
11

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de livekit/client-sdk-flutter

Todos los issues de livekit/client-sdk-flutter

Issues similares

Más issues de Dart

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.