Bug 218012 – Audio Volume reduces considerably on accepting the mic permissions.

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: Web Audio

Source code - https://github.com/ashishanand26cs/ashishanand26cs.github.io/blob/master/index.html 

Steps to reproduce:-

In "Website Settings" of Safari, set the microphone's permission to "Ask". Open page "https://ashishanand26cs.github.io" on safari(ios version 14.0.1)"
Clicking on the webpage generates Gunshots. Observe the volume of the gunshot for below two cases.

Case 1:-
On opening the webpage the popup generates "Would Like To Access the Microphone"
Press "Allow". Now press click on the white page. It will generate the Gunshots on every click.
Observer the audio volume.

Case 2:-
Again refresh the page. It will again generate "Would Like To Access the Microphone"
Press "Cancel". Now press click on the white page. It will generate the Gunshots on every click.
Observer the audio volume.


Audio Volume generated in "Case 1" is significantly lower than "Case 2".

[Chris Dumez]

Does not reproduce on macOS but I can reproduce on iOS 14.

[Smoley]

Also reproduces on iOS 13.5.1 using the provided link.

[Radar WebKit Bug Importer]

<rdar://problem/70588151>

Hi
Do we have any update on this issue? 
Is the root cause identified? When can we expect the fix for this issue?

[youenn fablet]

When starting capturing, we are changing of audio category which might explain the issue.The following fiddle helps: https://jsfiddle.net/af147yqz/

If you start capturing, then create the audio context, you will get the audio volume as high.

If you create the audio context, audio volume will be low and will stay like this, even after starting capture.
If during capture, you will suspend/resume the audio context, audio volume will be high.

Hopefully, that can help you find a temporary workaround.

We tried the WAR, however, unfortunately, it seems to be working just on a few devices - for several devices, the WAR does not have any effect

Few further isolations which we observed:
- Volume is also reset for pre-existing audio contexts, even just if a new audio context is created when recording starts
- On devices which WAR doesn't work, suspending/Resuming audio stream/track makes no difference

Devices on which WAR works: iPad Pro 12.9-in (Second Generation), iPhone 7, iPhone X
Devices on which WAR doesn't work: iPad Pro 11-in (Third Generation), iPhone XR

[:fippo]

I can reproduce quite reliably after finding out they key is rotating the device somehow.
I can reproduce on an iphone SE (2020) and both in iOS 14.1 and 14.2. Upgrading to 14.2 caused a (hopefullly) unrelated webaudio issue which makes the audio stutter for several seconds.

The minimal sample is at https://fippo.github.io/htmlthings/aadz4a.html
It plays a constant tone using webaudio and visualizes the audio level webrtc sees.

Steps to reproduce low audio volume:
1/ open Safari, put into portrait mode
2/ put phone on the desk, do not hold it
3/ open https://fippo.github.io/htmlthings/aadz4a.html
4/ click "play noise" button. This emits a constant tone.
5/ click "request getusermedia" button. Audio volume usually increases. Note that the graph which shows the audio level webrtc computes stays at 1.0
6/ reload, pick up phone, rotate to portrait mode, put phone on the desk
7/ click "play noise" button. This emits a constant tone roughly the same volume as in step 4.
8/ click "request getusermedia" button". Audio volume drops considerably. Note that the graph which shows the audio level webrtc computes stays at 1.0

For extra fun, continue testing:
9/ pick up phone, put in portrait mode, put down phone
10/ reload
11/ click "play noise" button followed by getUserMedia button
12/ Observe low volume

For even more fun, kill safari, then repeat but starting from landscape mode and switch to portrait mode.

https://bugs.webkit.org/show_bug.cgi?id=198545#c29 suggests rotation fixes *some* issue.
This sounds like some kind of "audio ducking" issue.
This is not detectable from what I can see.

Hi, I wonder if there were any updates on this issue?

This seems to be reproing without device rotation too for us

We are still seeing this issue on 14.3. The workaround mentioned is not working.

Do we have any updates on this issue? 
When can we expect the fix for this issue?

We are still seeing this issue on 14.4. 

If we play the audio element again(WAR) it increases the volume but only until 50 percent.

Is there a plan for a fix in some upcoming version?

[Andres Traumann]

We still have the bug on 14.5 beta.

[James Howard]

It looks like Safari uses the following options when setting the audio category to play and record:

auto options = AVAudioSessionCategoryOptionAllowBluetooth | AVAudioSessionCategoryOptionMixWithOthers;

https://git.webkit.org/?p=WebKit-https.git;a=blob;f=Source/WebCore/platform/mediastream/ios/AVAudioSessionCaptureDeviceManager.mm;hb=29d45f52c2db831d9b6a7d9e96dfd44624984c24#l110

I think this means when the mic turns on that the receiver speaker becomes the only one active (the little earpiece one on a phone). This is probably a reasonable set of options for when you're holding the phone like a phone, but it's maybe not great for video chat or music apps. Using AVAudioSessionCategoryOptionDefaultToSpeaker would be better for our use case, but I'm not sure what the fallout would be by changing it across the board. I kind of think maybe AVAudioSessionCategoryOptionDefaultToSpeaker better fits what most web apps want to do; most web apps aren't trying to just make phone calls.

[:fippo]

Would it be possible to use AVAudioSessionCategoryOptionDefaultToSpeaker when there is a stereo track playing?

[Andres Traumann]

The issue seems to have disappeared in 14.5. However, it seems there is now an opposite issue, on at least one device the volume seemed to slightly increase after asking for microphone permissions. Of course this new issue is a much smaller problem, at least in my use case.

[David Gölzhäuser]

I still see this issue on iOS 15 and iOS 15.1 Beta 2.

All workarounds do not work for me.

This issue still seems to be happening on iOS 15.
The audio is switching to receiver speakers on enabling mic

[David Gölzhäuser]

I am currently working on a workaround, I made some progress.


Here is our use case.

Web based WebRTC Application that initially receives a Video Stream, then when calling the remote peer the local and remote audio will be enabled

The current implementation acquired the devices local microphone stream and added its track to the RTCPeerConnection, this triggered a renegotiate and eventually in receiving the remote peers audio stream. => Remote Audio was emitted through the earpiece

I restructured this behavior because I noticed the correct speaker is used when first receiving the remote peers audio stream and then acquiring the local devices microphone stream. => Remote Audio was emitted through the speaker

However, this only works once per app livecycle (Cordova based App). So I am still working on it, but its an improvement.


FYI:
I simply add the empty Track `audioContext.createMediaStreamDestination().stream.getAudioTracks()[0]` to the RTCPeerConnection, then when the mic stream is acquired I simply replace the former added track with the local microphone track of the resulting RTCSender (from the RTCPeerConnections function `addTrack`)

[Varun D]

Thanks for the trick.
I tried this solution. This improved audio level - but only till the code acquired MIC stream.
If I deny the Mic permission when it is asked later - the volume still continued to be good. But as soon as I say 'yes' to mic permissions - volume goes to very low.
I am using iPhone XR with 15.1 iOS.
May I know what is your setup where it stayed High even after giving mic permissions? @David

(In reply to David Gölzhäuser from comment #17)
> I am currently working on a workaround, I made some progress.
> 
> 
> Here is our use case.
> 
> Web based WebRTC Application that initially receives a Video Stream, then
> when calling the remote peer the local and remote audio will be enabled
> 
> The current implementation acquired the devices local microphone stream and
> added its track to the RTCPeerConnection, this triggered a renegotiate and
> eventually in receiving the remote peers audio stream. => Remote Audio was
> emitted through the earpiece
> 
> I restructured this behavior because I noticed the correct speaker is used
> when first receiving the remote peers audio stream and then acquiring the
> local devices microphone stream. => Remote Audio was emitted through the
> speaker
> 
> However, this only works once per app livecycle (Cordova based App). So I am
> still working on it, but its an improvement.
> 
> 
> FYI:
> I simply add the empty Track
> `audioContext.createMediaStreamDestination().stream.getAudioTracks()[0]` to
> the RTCPeerConnection, then when the mic stream is acquired I simply replace
> the former added track with the local microphone track of the resulting
> RTCSender (from the RTCPeerConnections function `addTrack`)

[Varun D]

Update: the above trick did work for me in iOS chrome *once, but not always* - but never in Safari. 
(In reply to Varun D from comment #18)
> Thanks for the trick.
> I tried this solution. This improved audio level - but only till the code
> acquired MIC stream.
> If I deny the Mic permission when it is asked later - the volume still
> continued to be good. But as soon as I say 'yes' to mic permissions - volume
> goes to very low.
> I am using iPhone XR with 15.1 iOS.
> May I know what is your setup where it stayed High even after giving mic
> permissions? @David
> 
> (In reply to David Gölzhäuser from comment #17)
> > I am currently working on a workaround, I made some progress.
> > 
> > 
> > Here is our use case.
> > 
> > Web based WebRTC Application that initially receives a Video Stream, then
> > when calling the remote peer the local and remote audio will be enabled
> > 
> > The current implementation acquired the devices local microphone stream and
> > added its track to the RTCPeerConnection, this triggered a renegotiate and
> > eventually in receiving the remote peers audio stream. => Remote Audio was
> > emitted through the earpiece
> > 
> > I restructured this behavior because I noticed the correct speaker is used
> > when first receiving the remote peers audio stream and then acquiring the
> > local devices microphone stream. => Remote Audio was emitted through the
> > speaker
> > 
> > However, this only works once per app livecycle (Cordova based App). So I am
> > still working on it, but its an improvement.
> > 
> > 
> > FYI:
> > I simply add the empty Track
> > `audioContext.createMediaStreamDestination().stream.getAudioTracks()[0]` to
> > the RTCPeerConnection, then when the mic stream is acquired I simply replace
> > the former added track with the local microphone track of the resulting
> > RTCSender (from the RTCPeerConnections function `addTrack`)

[David Gölzhäuser]

Hi Varun,

This trick only works once per app session on WKWebView (which is also used by Chrome). I did not try this in the Safari Browser yet.

Try to close Chrome and reopen it after it worked once to see that it only works once per app session.

[Varun D]

(In reply to David Gölzhäuser from comment #20)
> Hi Varun,
> 
> This trick only works once per app session on WKWebView (which is also used
> by Chrome). I did not try this in the Safari Browser yet.
> 
> Try to close Chrome and reopen it after it worked once to see that it only
> works once per app session.

Thanks!
Did work on Safari as well.

[Aqly]

(In reply to David Gölzhäuser from comment #17)
> I am currently working on a workaround, I made some progress.
> 
> 
> Here is our use case.
> 
> Web based WebRTC Application that initially receives a Video Stream, then
> when calling the remote peer the local and remote audio will be enabled
> 
> The current implementation acquired the devices local microphone stream and
> added its track to the RTCPeerConnection, this triggered a renegotiate and
> eventually in receiving the remote peers audio stream. => Remote Audio was
> emitted through the earpiece
> 
> I restructured this behavior because I noticed the correct speaker is used
> when first receiving the remote peers audio stream and then acquiring the
> local devices microphone stream. => Remote Audio was emitted through the
> speaker
> 
> However, this only works once per app livecycle (Cordova based App). So I am
> still working on it, but its an improvement.
> 
> 
> FYI:
> I simply add the empty Track
> `audioContext.createMediaStreamDestination().stream.getAudioTracks()[0]` to
> the RTCPeerConnection, then when the mic stream is acquired I simply replace
> the former added track with the local microphone track of the resulting
> RTCSender (from the RTCPeerConnections function `addTrack`)

Hi,

Do you mind sharing sample codes on how you did it?

[ztb]

Is a patch being proposed to address this issue as it is very serious?

[David Gölzhäuser]

To shed a bit more light on this issue.

I created a issue using the Feedback-Assistent App on August the 3rd linking multiple WebKit bugs describing the same or similar issues (including this one).

After every Beta or Public release of iOS I check the behaviour and update the issue with the current state -> No Feedback whatsoever from Apple.

As our application relies on that WebRTC Audio Calls it is a critical issue. I also created an TSI (Technical Support Incident) as our Application is available in the AppStore. The response was like "You already created an issue, please use the issue to track it, we won't help you here." -> TSI wasted


Now we are in 2022 with no response from Apple whatsoever. 

This is a very serious bug.

[youenn fablet]

This is probably addressed by https://bugs.webkit.org/show_bug.cgi?id=233316.

[David Gölzhäuser]

Hey Youenn,

Thanks for taking care of https://bugs.webkit.org/show_bug.cgi?id=233752 and for checking out this issue.

I just revisited the issue after the new year break and indeed, it appears to be fixed in iOS 15.3 Beta 1. I just tested it myself in the office and not via remote. (I don't know why I did suspect it not to work when I tested it in Homeoffice.)

Thanks for taking care of this 👍

[youenn fablet]

(In reply to David Gölzhäuser from comment #26)
> Hey Youenn,
> 
> Thanks for taking care of https://bugs.webkit.org/show_bug.cgi?id=233752 and
> for checking out this issue.
> 
> I just revisited the issue after the new year break and indeed, it appears
> to be fixed in iOS 15.3 Beta 1. I just tested it myself in the office and
> not via remote. (I don't know why I did suspect it not to work when I tested
> it in Homeoffice.)
> 
> Thanks for taking care of this 👍

I am not sure the fix is in iOS 15.3 beta.

[David Gölzhäuser]

I will take a close look on any upcoming iOS Beta. At least our issue is fixed on that iOS version. It's "Case 2" of the initial post.

[ztb]

Hi Youenn,

Appreciate you being responsive to the community.

2 questions....

1st question....

Does this patch also address https://bugs.webkit.org/show_bug.cgi?id=230902 as I understood the core issue to be the same and should bot be fixed now in your opinion?

Second question.....

Is there any way to track when fixes get into iOS?

There are several critical bugs that are closed (https://bugs.webkit.org/show_bug.cgi?id=232822 for example) or have submitted patches but aren't in any version of iOS and once they are closed no more updates happen.

Am I missing where the released iOS version is being documented?

[David Gölzhäuser]

After updating to iOS 15.3 Beta 2 I am able to reproduce this issue again

[StillTravelling]

This is definitely happening to me on iPad Pro 2019 on 15.4 beta 1. Creating the context before the capturing does not resolve the issue. Stopping the mic track does not return the volume to normal.

Testing on iPhone XS on 15.4 beta 1 results in some differences. Stopping the mic track does not return the volume to normal, however if I restart the mic capture again after originally getting permissions, the volume is normal.

[youenn fablet]

(In reply to StillTravelling from comment #31)
> This is definitely happening to me on iPad Pro 2019 on 15.4 beta 1. Creating
> the context before the capturing does not resolve the issue. Stopping the
> mic track does not return the volume to normal.

The fix is only affecting audio rendering of MediaStreamTrack, not WebAudio (potentially other non-MediaStreamTrack media elements as well).
The current workaround for getting regular volume for web audio is to render WebAudio through a MediaStreamAudioDestinationNode. 

> Testing on iPhone XS on 15.4 beta 1 results in some differences. Stopping
> the mic track does not return the volume to normal, however if I restart the
> mic capture again after originally getting permissions, the volume is normal.

Thanks for the testing.
I filed https://bugs.webkit.org/show_bug.cgi?id=236219, let's continue the discussion there.

[Brent Fulgham]

Please continue the investigation of remaining issues in Bug 236219.

[Bryce Aebi]

Issue persists on iOS 16.2

Our entire web app is rendered unusable on iPhone due to this bug. I am happy to assist in any way to get this bug resolved. Thank you

[Bryce Aebi]

Issue persists on iOS 16.2

Our entire web app is rendered unusable on iPhone due to this bug. I am happy to assist in any way to get this bug resolved. Thank you

[Bryce Aebi]

I've mentioned this on the related bug, but will repeat here as it's relevant to this one as well. 

I have tried both WebAudio and routing the WebAudio through a MediaStreamAudioDestinationNode. This was on both iOS 16.2 and iOS 16.4. The volume issue persists regardless of the audio routing or iOS version.

[Bryce Aebi]

SOLUTION FOR POSTERITY:

The solution to this issue is to manually set the following BEFORE mic capture:

navigator.audioSession.type = 'play-and-record';

And then running the following AFTER mic capture

navigator.audioSession.type = 'playback';

I have confirmed that this resolves the issue in iOS 16.4 beta 2. More details about this setting can be viewed here: https://github.com/w3c/audio-session/blob/main/explainer.md

[Justin Higgins]

Hey Bryce, is the navigator.audioSession.type API only available on iOS 16.4 beta 2? Not seeing it on iOS 16.2

[Bryce Aebi]

Justin, I am not sure. I updated my phone to 16.4 beta 2 and haven't had a chance to test on lower versions yet. What do you mean when you say you are "not seeing it on iOS 16.2"? Are you seeing an error in the console when you try to access it?

[Justin Higgins]

> Are you seeing an error in the console when you try to access it
Hey Bryce, yep, when in the js console for iOS safari 16.2, i get `undefined` for navigator.audioSession

[Bryce Aebi]

Thanks for the response Justin, that's good to know. Do you mind testing if 16.3 works?

I'm guessing on 16.2 and below there isn't really any recourse then.

[Justin Higgins]

> Thanks for the response Justin, that's good to know. Do you mind testing if 16.3 works?

Same issue on 16.3, I get `undefined` for navigator.audioSession in the js console

[Tobi (onexip.com)]

setting the audioSession type back to "playback" after the microphone track is stopped (or WebSpeech is stopped) only helps sometimes, sometimes not. It seams that setting the type doesn't always works.

[Tobi (onexip.com)]

any news here fixing the bug? Currently it's not possible to use recording and playback simultaniously on iOS :( On Android and native iOS it works.

[Taimoor]

None of the solutions work for me. I still see this issue in iOS 17.3.1. Please suggest any work arounds, our business rely on this and we are losing customers.

[Tobi (onexip.com)]

Additionally to this bug, we have an "audio ducking problem". So If you play back audio using WebAudio and open the microphone stream in parallel, the audio volume decreased if the user talks to the microphone. Its like a "talk over" or "audio ducking" feature which can't be disabled.

Event disabling the mic track does not help.

[Tobi (onexip.com)]

no news here?