Unable to send audio output to earpiece for WebRTC audio-only use case on Android phones
Reported by
ryan.hil...@gmail.com,
Sep 19 2016
|
|||||||
Issue descriptionSteps to reproduce the problem: 1. Browse to https://webrtc.github.io/samples/src/content/devices/input-output/ and allow use of microphone, camera 2. Click the drop-down for "Audio output destination". Only "Default" is shown as an option (Default supports speakerphone/headphones only, underlying function call is navigator.mediaDevices.enumerateDevices()). What is the expected behavior? An output device specific to the earpiece is also shown -or- A setting is made available to toggle the audio between speakerphone and earpiece when headphones are not connected What went wrong? For a WebRTC call from Android that is audio-only, the user should be able to use the earpiece as they would a traditional call in the phone app. In the current state they can only use speakerphone or headphones. Did this work before? No Chrome version: 55.0.2860.0 Channel: stable OS Version: 6.0.1 Flash Version: Disabled Unsure if this qualifies as a bug or feature, started as bug.
,
Sep 21 2016
henrika@ I assume Android does not expose the devices to Chrome? If so, I guess a change is needed in Android rather than Chrome?
,
Sep 21 2016
guidou@ works in this area and should know the latest details.
,
Sep 21 2016
This is basically a request for setSinkId on Android. setSinkId allows changing the output device for a given media element and is supported on Chromium on desktop platforms. The problem with Android is that, at the moment, it is not possible for an application to send different audio streams to different output devices and switch the devices for each stream independently, as required by setSinkId. We plan to implement setSinkId on Android once the platform makes it feasible. Unfortunately, there is no ETA on that.
,
Sep 22 2016
,
Oct 21 2016
Is there a feature request in place for the Android team, and if so can you provide any way to track their progress?
,
Mar 6 2017
,
Aug 17 2017
Any updates on this issue?
,
Aug 18 2017
No new updates.
,
Aug 18 2017
,
Aug 18 2017
,
May 22 2018
I don't think setSinkId is the way to solve this. I recently discovered that, on my android device, the volume of <audio> elements is normally controlled by the 'media' volume but is controlled by the 'call/ringer' volume after getUserMedia has been called (and returned a MediaStream). The result is <audio> elements not related to the user media now play at the wrong volume. I think a better solution would be some means to indicate the purpose of the <audio> element, such as media, voice call or notification. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by candr...@chromium.org
, Sep 20 2016Owner: jansson@chromium.org
Status: Assigned (was: Unconfirmed)