[Webkit-unassigned] [Bug 259193] New: 1-channel hardware devices from getUserMedia() appears to have silence in a second track

[bugzilla-daemon at webkit.org]

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

            Bug ID: 259193
           Summary: 1-channel hardware devices from getUserMedia() appears
                    to have silence in a second track
           Product: WebKit
           Version: Safari 16
          Hardware: All
                OS: Unspecified
            Status: NEW
          Severity: Major
          Priority: P2
         Component: Media
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: marc+webkit at cleanfeed.net

Created attachment 467034

  --> https://bugs.webkit.org/attachment.cgi?id=467034&action=review

Safari microphone test (see comments for more information)

When a mono device is opened our experiements suggest this results (incorrectly) in a 2 channel stream with silence in the second channel.

In this case the mono device is Macbook internal microphone with echoCancellation = false, on Safari 15.4 and 16.0.

Simplest test case is connecting the microphone directly to <audio> node (see attached test case -- beware as it loops back audio). Observe different behaviour in Chromium and Safari.

Also various experiments in WebAudio suggest the stream is actually stereo (see test case which attempts to up-mix to stereo)

Because Webkit does not implement "channelCount" on the MediaTrack we have to infer the actual number of channels from experimenting in WebAudio, WebRTC.

In practice this breaks the users expectations if they use a regular microphone. And with ambiguitity between a 1 channel + silence stream and an actual stereo one, we can't sensibly 
workaround in WebAudio either.

The behaviour on Chromium seems correct -- it states the MediaTrack as 1 channel and up-mixes as appropriate.

The behaviour on older Safari/macOS/MacBook seemed to be correct, making this a regression. A change in hardware or OS leaves Safari seeing mono audio devices where previously it did not? It's not clear at the moment.

-- 
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/20230713/bcdab770/attachment.htm>