macOS Safari 15.2 Audio Echo Issue after camera pause/unpause

• Component: WebRTC
• Status: RESOLVED FIXED

Steps to reproduce the issue:
1. Go to https://webrtc.github.io/samples/src/content/devices/input-output/ with Safari 15.
2. Click the camera mute button in the address bar.
3. hit "pause" 
4. then, hit "unpause" 
5. Observe the annoying disturbance of hearing yourself, even though you shouldn’t hear anything as there is no one else in the session.

[youenn fablet]

Tested locally on a recent Safari and I am not sure I am able to reproduce.
Hearing yourself should happen before pause and after unpause.
Are you saying that, before pausing, echo canceller is working great (you can hear some limited feedback) while after unpausing, you are hearing much more feedback?
Or is it that volume changed somehow?

I actually made a quick jsfiddle instead of using the webrtc.github.io samples. 

This is the link - https://jsfiddle.net/othm7a5k/3/. 

Can you please try with this one and let me know if you are able to reproduce the issue? Basically, if you "pause" and then "un-pause" the video using the camera icon in the address bar, you will be able to hear yourself which is not observed when you just join. I'm on Safari 15.2, macOS 12.1 btw.

[Radar WebKit Bug Importer]

<rdar://problem/88297045>

[Daniel ORorke - Vonage]

I have discovered that it is also possible to reproduce this bug simply by enabling screen sharing.

If you share your screen, this should not cause audio loopback through the speakers.

I have also observed that changing the audio input device to something else resolves the problem.

[Daniel ORorke - Vonage]

(In reply to youenn fablet from comment #1)
> Tested locally on a recent Safari and I am not sure I am able to reproduce.
> Hearing yourself should happen before pause and after unpause.
> Are you saying that, before pausing, echo canceller is working great (you
> can hear some limited feedback) while after unpausing, you are hearing much
> more feedback?
> Or is it that volume changed somehow?

Hi Youenn!
If you are not subscribed to any media (only publishing into the abyss of the internet), you should not hear yourself.
Safari seems to play the audio, even when not subscribed to anything.
This is not related to echo canceler. Something is piping audio input to the output channel separate from WebRTC or echo cancelation.

-Daniel

[Daniel ORorke - Vonage]

For some reason, this is becoming increasingly common. Please prioritize, as it renders video sessions unusable from the audio disturbance.

I have observed that if another party is screen sharing, the echo is observed on join - no user interaction is necessary.

repro:
User A: Publish camera, mic, and screen share.
Broken User B: Publish camera and mic on joining a session with User A.

Broken User B can hear themselves, and this causes considerable feedback as it is passed unchecked through the noise canceler to User A. If it gets loud enough, the noise canceler clamps down and stops all noise but it restarts as soon as any sound is heard through the microphone.


Observation: In this condition, it is as though I have made a direct connection from the mic to the speakers, outside of the typical WebRTC subscription.
When wearing headphones, I can hear myself (but no feedback is picked up by the mic since it is played locally to my headphones). You should not hear yourself unless you are subscribing to yourself.

Changing the microphone to a different device, then back to the original device may temporarily solve this issue.

[Daniel ORorke - Vonage]

Hello Apple,
Please address this!

It appears the audio problem is created if:
1. Disable / enable video through browser controls
2. Enable screen sharing
3. Change microphone source

Occasionally, changing the audio input source fixes the issue until another of the above actions is taken - but it is inconsistent and more likely to break it if audio is not already broken and therefore not an acceptable workaround.

This renders RTC sessions unusable in quite short order if you're just listening to mic/speaker feedback and no one is able to be heard.

This is much more impacting than the issue with Nat64IPv4 addressing.

[youenn fablet]

Created attachment 453712 [details]
Patch

[EWS]

Committed r290778 (248022@main): <https://commits.webkit.org/248022@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 453712 [details].

[youenn fablet]

*** Bug 237523 has been marked as a duplicate of this bug. ***

[Daniel ORorke - Vonage]

💯 Thank you! This will radically improve the experience for all using Safari for video calls.

[Daniel ORorke - Vonage]

(In reply to youenn fablet from comment #8)
> Created attachment 453712 [details]
> Patch

Hi Youenn,
I note that Mac OS Safari Tech Preview Release 141 (15.4) doesn't contain this fix.
Is it possible to know which version of Safari we should end our workaround for?

Thanks,
Daniel

[youenn fablet]

(In reply to Daniel ORorke - Vonage from comment #12)
> (In reply to youenn fablet from comment #8)
> > Created attachment 453712 [details]
> > Patch
> 
> Hi Youenn,
> I note that Mac OS Safari Tech Preview Release 141 (15.4) doesn't contain
> this fix.
> Is it possible to know which version of Safari we should end our workaround
> for?
> 
> Thanks,
> Daniel

We are working on it, when something is made available, I will try to mention it here.

[youenn fablet]

*** Bug 238456 has been marked as a duplicate of this bug. ***

[Daniel ORorke - Vonage]

Note to anyone else tracking this - 
This is verified fixed in Safari iOS 15.4 and currently appears to be fixed in Safari Tech Preview using WebKit R143. It is not yet in Safari stable releases.

[Eric Carlson]

*** Bug 235433 has been marked as a duplicate of this bug. ***

[Brent Fulgham]

This fix shipped with Safari 15.5 (all platforms).

[youenn fablet]

*** Bug 241492 has been marked as a duplicate of this bug. ***