[Webkit-unassigned] [Bug 231422] REGRESSION (iOS 15): Distorted audio output when AirPods are connected but not worn at the beginning of a WebRTC call

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=231422

Wolfe Lienhardt <wolfe.lienhardt at amwell.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wolfe.lienhardt at amwell.com

--- Comment #8 from Wolfe Lienhardt <wolfe.lienhardt at amwell.com> ---
Some additional context for this and adding to @Mitch's issue.

The problem seems to only impact iOS/Mobile Safari and it's specifically when switching between the native audio device and external audio devices with a different sample rate.

Below is my experience interpretation of what is happening, albeit I have no idea if this is *actually* the underlying cause.

Bluetooth headsets (including airpods/pixel buds/whatever) generally run at 16khz  and the native device sample rate is generally at 44.1khz or 48khz.

In digging into this issue we've discovered it manifests in two ways depending on the order of operations, but both seem to be the same underlying cause. We've dubbed these 'chipmunk' and 'demon' mode depending on the way it manifests.

You can reproduce these on https://p2p.chat/ when it works -- the site itself is a bit finicky on safari.

to reproduce “demon”

1. get into a webrtc call without a bluetooth headset on
2. turn on the bluetooth headset mid call so that it pairs/directs audio to the device
3. refresh the browser

You should hear “demon voice” as the 48khz (native sample rate) audio is being interpreted at 16khz (headset sample rate) resulting in lost audio data and lower perceived pitch (I assume).


to reproduce “chipmunk”

1. get into a webrtc call with a bluetooth headset already on
2. turn the headset off mid call
3. refresh the device

You should hear “chipmunk voice” as the 16khz (headset sample rate) audio is being interpreted at 48khz (native sample rate) resulting in gaps in the sample buffer and a higher perceived pitch (again, I'm assuming).



The bigger problem is this is basically terminal. Once in the bad state, no amount of refreshing or re-negotiating the webrtc call will fix it. The only way I've found to fix it is to basically walk backwards through the steps that caused it, which isn't something I can expect users to do when part of those step involve turning on/off a headset.

The *good* news is in my testing after upgrading from 15.2 to 15.4.1 -- I can no longer reproduce this issue. I'd like some clarification from someone internal to let me know if this actually fixed however.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220413/037bbec8/attachment-0001.htm>