Bug 235544 - macOS Safari 15.2 Audio Echo Issue after camera pause/unpause
Summary: macOS Safari 15.2 Audio Echo Issue after camera pause/unpause
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebRTC (show other bugs)
Version: Safari 15
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: youenn fablet
URL:
Keywords: InRadar
: 235433 237523 238456 241492 (view as bug list)
Depends on:
Blocks:
 
Reported: 2022-01-24 15:13 PST by misha.behei
Modified: 2022-06-16 23:22 PDT (History)
22 users (show)

See Also:


Attachments
Patch (7.43 KB, patch)
2022-03-03 02:14 PST, youenn fablet
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description misha.behei 2022-01-24 15:13:00 PST
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.
Comment 1 youenn fablet 2022-01-25 00:49:59 PST
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?
Comment 2 misha.behei 2022-01-25 15:53:16 PST
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.
Comment 3 Radar WebKit Bug Importer 2022-01-31 15:13:34 PST
<rdar://problem/88297045>
Comment 4 Daniel ORorke - Vonage 2022-02-08 08:48:40 PST
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.
Comment 5 Daniel ORorke - Vonage 2022-02-18 11:08:45 PST
(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
Comment 6 Daniel ORorke - Vonage 2022-02-18 11:18:31 PST
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.
Comment 7 Daniel ORorke - Vonage 2022-02-28 15:03:29 PST
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.
Comment 8 youenn fablet 2022-03-03 02:14:15 PST
Created attachment 453712 [details]
Patch
Comment 9 EWS 2022-03-03 08:59:10 PST
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].
Comment 10 youenn fablet 2022-03-07 05:29:34 PST
*** Bug 237523 has been marked as a duplicate of this bug. ***
Comment 11 Daniel ORorke - Vonage 2022-03-21 16:35:21 PDT
💯 Thank you! This will radically improve the experience for all using Safari for video calls.
Comment 12 Daniel ORorke - Vonage 2022-03-23 16:27:16 PDT
(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
Comment 13 youenn fablet 2022-03-28 08:00:00 PDT
(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.
Comment 14 youenn fablet 2022-03-28 08:00:39 PDT
*** Bug 238456 has been marked as a duplicate of this bug. ***
Comment 15 Daniel ORorke - Vonage 2022-04-20 15:42:30 PDT
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.
Comment 16 Eric Carlson 2022-05-03 14:57:48 PDT
*** Bug 235433 has been marked as a duplicate of this bug. ***
Comment 17 Brent Fulgham 2022-05-26 15:05:03 PDT
This fix shipped with Safari 15.5 (all platforms).
Comment 18 youenn fablet 2022-06-16 23:22:59 PDT
*** Bug 241492 has been marked as a duplicate of this bug. ***