Bug 211192 – USB microphone not recognized iOS Safari

• Component: WebRTC
• Status: REOPENED

[Marc Bakos]

Created attachment 397975 [details]
Audio Tools (and other apps) discovers USB microphone connected to iOS, Safari does not.

Safari (iOS) doesn’t allow USB microphone devices through to any WebRTC enabled websites (getUserMedia). 
The Apple USB to lightning adapter is recognized by iOS, but is unable to perform with Safari. The USB microphone (in this case, a ATR2100); is detected on every other native app which enables microphones. 

The USB microphone is picked up in all native apps, attached example shows the microphone being correctly being discovered by iOS as described in an app called 'AudioTools'. However, with two WebRTC websites, (cleanfeed.net and WebRTC Samples); this microphone isn't being identified: https://webrtc.github.io/samples/src/content/devices/input-output/

Regards

[Radar WebKit Bug Importer]

<rdar://problem/62607313>

[Marc Bakos]

Hello, is there any further feedback on this report?

[Bill]

Noticed this issue as well. Seems like a fairly big problem for certain types of apps. Any updates?

[Eric Carlson]

Created attachment 413698 [details]
Patch

[youenn fablet]

Comment on attachment 413698 [details]
Patch

Great to have the fix!

View in context: https://bugs.webkit.org/attachment.cgi?id=413698&action=review

> Source/WebCore/platform/mediastream/mac/CoreAudioCaptureDevice.h:52
> +    bool defaultDevice();

isDefaultDevice

> Source/WebCore/platform/mediastream/mac/CoreAudioCaptureDeviceManager.cpp:292
> +    if (haveDeviceChanges && notify == NotifyIfDevicesHaveChanged::Notify) {

Why not firing a device change event in case default changes?
This might be useful so that applications call again enumerateDevices and might notice the change.

[Eric Carlson]

Created attachment 413713 [details]
Patch

[Eric Carlson]

Created attachment 413725 [details]
Patch

[Eric Carlson]

Created attachment 413753 [details]
Patch

[youenn fablet]

Comment on attachment 413753 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=413753&action=review

> Source/WebCore/platform/mediastream/ios/AVAudioSessionCaptureDevice.mm:44
> +    setIsDefault(defaultInput && [defaultInput.UID isEqualToString:deviceInput.UID]);

Having two AVAudioSessionPortDescription* might be a bit confusing
Since we are only using defaultInput to check whether deviceInput is default, we could just pass isDefault value here or add a setter for this value that would be called later.

> Source/WebCore/platform/mediastream/ios/AVAudioSessionCaptureDeviceManager.mm:52
> +    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(routeDidChange:) name:PAL::get_AVFoundation_AVAudioSessionRouteChangeNotification() object:session];

Is it always calling from the main thread?

> Source/WebCore/platform/mediastream/ios/AVAudioSessionCaptureDeviceManager.mm:158
> +        LOG_ERROR("Failed to activate audio session with error: %@.", error.localizedDescription);

RELEASE_LOG?

> Source/WebCore/platform/mediastream/mac/CoreAudioCaptureDevice.cpp:70
> +        err = AudioObjectGetPropertyData(static_cast<UInt32>(deviceID), &address, 0, nullptr, &dataSize, &localizedName);

Logging maybe?

> Source/WebCore/platform/mediastream/mac/CoreAudioCaptureDevice.cpp:110
> +    setIsDefault(!err && defaultID == m_deviceID);

logging?

> Source/WebCore/platform/mediastream/mac/CoreAudioCaptureDeviceManager.cpp:154
> +                CoreAudioCaptureDeviceManager::singleton().scheduleUpdateCaptureDevices();

Sounds good to do this indeed.
The other changes of this method are refactoring and are not really changing any behavior, is that correct?

> Source/WebCore/platform/mediastream/mac/CoreAudioCaptureDeviceManager.cpp:267
> +            auto& newState = audioDevices[cptr];

s/oldState/oldDevice/
s/newState/newDevice/

[Eric Carlson]

Created attachment 413825 [details]
Patch for landing

[Eric Carlson]

Comment on attachment 413753 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=413753&action=review

>> Source/WebCore/platform/mediastream/ios/AVAudioSessionCaptureDevice.mm:44
>> +    setIsDefault(defaultInput && [defaultInput.UID isEqualToString:deviceInput.UID]);
> 
> Having two AVAudioSessionPortDescription* might be a bit confusing
> Since we are only using defaultInput to check whether deviceInput is default, we could just pass isDefault value here or add a setter for this value that would be called later.

It might be slightly confusing, but it seems better to me to keep the logic for what makes an input default in the class that represents the input.

>> Source/WebCore/platform/mediastream/ios/AVAudioSessionCaptureDeviceManager.mm:52
>> +    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(routeDidChange:) name:PAL::get_AVFoundation_AVAudioSessionRouteChangeNotification() object:session];
> 
> Is it always calling from the main thread?

Good point, I don't know if it is or not so I'll add a check.

>> Source/WebCore/platform/mediastream/ios/AVAudioSessionCaptureDeviceManager.mm:158
>> +        LOG_ERROR("Failed to activate audio session with error: %@.", error.localizedDescription);
> 
> RELEASE_LOG?

Changed.

>> Source/WebCore/platform/mediastream/mac/CoreAudioCaptureDevice.cpp:110
>> +    setIsDefault(!err && defaultID == m_deviceID);
> 
> logging?

Fixed.

>> Source/WebCore/platform/mediastream/mac/CoreAudioCaptureDeviceManager.cpp:154
>> +                CoreAudioCaptureDeviceManager::singleton().scheduleUpdateCaptureDevices();
> 
> Sounds good to do this indeed.
> The other changes of this method are refactoring and are not really changing any behavior, is that correct?

Correct, the other changes are just minor cleanup.

>> Source/WebCore/platform/mediastream/mac/CoreAudioCaptureDeviceManager.cpp:267
>> +            auto& newState = audioDevices[cptr];
> 
> s/oldState/oldDevice/
> s/newState/newDevice/

Fixed

[EWS]

Committed r269688: <https://trac.webkit.org/changeset/269688>

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

[Bill]

Thanks for fixing this. Do you know what version of iOS will have the change?

[Bill]

Hey everyone, I'm still seeing this issue on iPad OS 14.5 beta. Should that version have the fix? It seems like this was merged awhile ago.

[Marc Bakos]

As per my email to Eric, I upgraded to 14.5 beta 6 on my spare iPhone XS.

Unfortunately I’m still not seeing the USB device enumerated. 

I’m using a Lighting cable to USB adapter (official Apple) and have an Audio Technica ATR2100-USB plugged in. The device works in other apps; just not Safari. 

Both my test on Cleanfeed and WebRTC example pages (https://webrtc.github.io/samples/src/content/devices/input-output) do not display the input device.

I've reopened the ticket for confirmation.

[Marc Bakos]

Tested on iOS 15 Beta (build 19A5318f); Safari is able to enumerate the device correctly; however upon selecting it, it doesn't open the device. 

In fact it just reverts the input back to the built in microphone of the device, despite its selection in the device selection menu.

If you'd like some more information, please let me know. It seems incredibly close!

[Eric Carlson]

(In reply to Marc Bakos from comment #16)
> Tested on iOS 15 Beta (build 19A5318f); Safari is able to enumerate the
> device correctly; however upon selecting it, it doesn't open the device. 
> 
> In fact it just reverts the input back to the built in microphone of the
> device, despite its selection in the device selection menu.
> 
> If you'd like some more information, please let me know. It seems incredibly
> close!

r280702 (bug 228753) should fix the inability to select some devices.

[Marc Bakos]

Thanks Eric. I have reviewed the latest iOS 15 Beta 8 build 19A5340a on iPhone Xs and I now see the USB device listed as 'Advanced USB Audio Device', though it is still not being used.

I'm guessing this is just a case of waiting for the patch 280702 to land in a build to correct this? I'll keep my eyes peeled for Beta 9, or the gold seed.

Dear all,

chiming in on this.

Has this change landed in either iOS 15 release version or 15.1 beta 3?

I'm not able to access an external audio interface in these version using an iPhone 6s. The interface is listed correctly but still the built-in mic is used, no matter if I select the external audio interface or not.

Tested with https://webrtc.github.io/samples/src/content/devices/input-output/ and cleanfeed.

Any help would be appreciated!


Regards
Tim

[Marc Bakos]

Hi all,

iOS 15.2.1 has been tested, with still no resolve. 
The USB device is enumerated, but still cannot be used. 

I made a video to demonstrate the issue: 
https://www.youtube.com/watch?v=V5BobU8vaBg

I can confirm that the correct device ID is selected, but the the device is still not opened correctly. It continues using the audio from the built in microphone.

If there is further information I can give, please let me know.

Thanks
Marc

[Antti Laitinen]

Hello everyone!

We're having this same issue in Soundtrap's iOS client.
You can't use an iRig for example. It's detected as an input device, but if you try to use it, then the incoming audio will come from the built-in mic.

getUserMedia() returns a MediaStream which has iRig in its label, but the audio still comes from the built-in mic.

Here's a simple piece of code which should be able to reproduce the problem: https://codepen.io/laiskimus/pen/WNXJYGb

That works in desktop browsers, but in mobile Safari you always get audio from the built-in mic.

[Marc Bakos]

Hello. I see there has been a lot of input to this ticket, though I'm afraid the user experience has recently got worse in recent iOS releases. 

For example, USB audio devices connected to iOS devices now don't even output audio from Safari. 

It is still not possible to correctly use the enumerated device.

Could someone kindly update this ticket as to whether it is possible to iron out these issues and finally get this bug resolved?

[Hastings]

As of August 2024, this is still not fixed- selecting the USB Microphone appears to work, and the stream.getAudioTracks()[0].label matches the label of the USB device, but the audio comes from the onboard microphone.

[PhungDuong]

This error still exists on iOS/iPadOS 17 and the latest version is iOS/iPadOS  18.0.
Connected Bluetooth, but the audio comes still from iPhone/iPad speaker.

[Dan M]

Just wanted to confirm, seeing this on iOS 18.1 with iPhone 14 Pro Max, still.

[PhungDuong]

Bug is still reproducible on iOS/iPad 18.2.1

This critical issue and limitation persists it seems.  It's not with all microphones; but the vast majority.

I did a YouTube some while ago with video detailing the issue for my own app's users, as its a very common issue and it's me, as the developer, who gets all the blame from the end users. I very much welcome being corrected however; if there is a solution, please let me know.

https://www.youtube.com/watch?v=BBus_S8iJUE

I point out in the video that certain Apple certified "communication/headset" devices work, but most others do not. It's a source of great frustration and has been for several years now.

Users facing this issue either switch to using TRRS or just switch to Android. Given the lack of video controls, like exposure/auto-focus, Apple is losing professional users to these oversights.

I would happily work with Apple to test or field-trial solutions. I have a large user base of starved users who greatly want this feature added/fixed. I also welcome the option to be allowed to install non-webkit browsers that might support this feature instead.

Regards

[PhungDuong]

Bug is still reproducible on iOS/iPad 18.4