bluetooth – Expose Audio Output Device & Route Change Listener in Flutter WebRTC

Title: Flutter WebRTC audio route auto-switches mid-call and no API to observe / control current audio output device

Question:

In Flutter WebRTC on both Android and iOS, audio routing is handled internally by WebRTC and the platform, but the plugin does not expose:

– The initially selected audio output device when a call starts
– The currently active audio output device during a call
– Any listener / callback when the audio route changes

This makes it very difficult to build a stable call UI and reliably control audio routing.

Problem Description

In our application:

– We manually change the audio output during an ongoing call (earpiece / speaker / bluetooth).
– After a few seconds, WebRTC automatically switches the audio route back to the system default.
– There is no public API to:

  • Determine which audio route is currently active
  • Detect when WebRTC or the system changes the route
  • Keep the UI synchronized with the actual routing state

As a result:

– The UI can show an incorrect icon (for example, showing “speaker” while audio is playing through bluetooth).
– User-selected routes are overridden automatically.
– Implementing stable call controls similar to WhatsApp or Telegram is not possible with the current API.

Expected Behavior / Proposed API

The plugin should ideally expose:

1. Initial audio output device at call start

getInitialAudioOutputDevice()  

Returns the audio route selected by WebRTC when the call begins.

2. Real-time audio route change listener

onAudioOutputDeviceChanged((device) {  
    // Possible values: SPEAKER, EARPIECE, BLUETOOTH, WIRED  
});  

Notifies the Flutter layer whenever the active audio route changes, whether triggered by the system or internally by WebRTC.

3. (Optional) Ability to lock / force a selected route

An API to prevent WebRTC from automatically switching the route back after a manual user selection.

Use Cases

This functionality is required to:

– Display the correct call UI icon (speaker / earpiece / bluetooth)
– Automatically prioritize bluetooth when a device is connected
– Prevent mid-call route changes overriding the user’s choice
– Keep the UI synchronized with the actual audio routing state

Platforms Affected

– Android — AudioManager, Bluetooth SCO, wired headset routing
– iOS — AVAudioSession route change handling

Additional Observations

During testing:

– After calling setSpeakerphoneOn(true), the audio route switches back to earpiece automatically after approximately 2–5 seconds.
– This happens without any callback or notification to the Flutter layer.

This appears to be a design limitation in the current Flutter WebRTC plugin and prevents reliable audio routing control in production call applications.

Question

Is there any supported way in Flutter WebRTC to:

– Get the current active audio output device?
– Listen for audio route changes in real time?
– Prevent WebRTC from overriding a manually selected audio route?

Or is forking / modifying the native WebRTC audio layer the only reliable solution?

Read more here: Source link

bluetooth – Expose Audio Output Device & Route Change Listener in Flutter WebRTC

Title: Flutter WebRTC audio route auto-switches mid-call and no API to observe / control current audio output device

Question:

In Flutter WebRTC on both Android and iOS, audio routing is handled internally by WebRTC and the platform, but the plugin does not expose:

– The initially selected audio output device when a call starts
– The currently active audio output device during a call
– Any listener / callback when the audio route changes

This makes it very difficult to build a stable call UI and reliably control audio routing.

Problem Description

In our application:

– We manually change the audio output during an ongoing call (earpiece / speaker / bluetooth).
– After a few seconds, WebRTC automatically switches the audio route back to the system default.
– There is no public API to:

  • Determine which audio route is currently active
  • Detect when WebRTC or the system changes the route
  • Keep the UI synchronized with the actual routing state

As a result:

– The UI can show an incorrect icon (for example, showing “speaker” while audio is playing through bluetooth).
– User-selected routes are overridden automatically.
– Implementing stable call controls similar to WhatsApp or Telegram is not possible with the current API.

Expected Behavior / Proposed API

The plugin should ideally expose:

1. Initial audio output device at call start

getInitialAudioOutputDevice()  

Returns the audio route selected by WebRTC when the call begins.

2. Real-time audio route change listener

onAudioOutputDeviceChanged((device) {  
    // Possible values: SPEAKER, EARPIECE, BLUETOOTH, WIRED  
});  

Notifies the Flutter layer whenever the active audio route changes, whether triggered by the system or internally by WebRTC.

3. (Optional) Ability to lock / force a selected route

An API to prevent WebRTC from automatically switching the route back after a manual user selection.

Use Cases

This functionality is required to:

– Display the correct call UI icon (speaker / earpiece / bluetooth)
– Automatically prioritize bluetooth when a device is connected
– Prevent mid-call route changes overriding the user’s choice
– Keep the UI synchronized with the actual audio routing state

Platforms Affected

– Android — AudioManager, Bluetooth SCO, wired headset routing
– iOS — AVAudioSession route change handling

Additional Observations

During testing:

– After calling setSpeakerphoneOn(true), the audio route switches back to earpiece automatically after approximately 2–5 seconds.
– This happens without any callback or notification to the Flutter layer.

This appears to be a design limitation in the current Flutter WebRTC plugin and prevents reliable audio routing control in production call applications.

Question

Is there any supported way in Flutter WebRTC to:

– Get the current active audio output device?
– Listen for audio route changes in real time?
– Prevent WebRTC from overriding a manually selected audio route?

Or is forking / modifying the native WebRTC audio layer the only reliable solution?

Read more here: Source link