[Webkit-unassigned] [Bug 244203] New: recording audio using audioworklet produces corrupted data

[bugzilla-daemon at webkit.org]

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

            Bug ID: 244203
           Summary: recording audio using audioworklet produces corrupted
                    data
           Product: WebKit
           Version: Safari Technology Preview
          Hardware: Mac (Intel)
                OS: macOS 12
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Web Audio
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: jk at numfum.com
                CC: cdumez at apple.com

When the issue is hit. Recording someone counting numbers 1,2,3,4,5,6,7,8,9,10 will yield samples containing something along the lines of 2,3, 5,6,7,  9,10. 

We have created a minimal test case for the issue. It records audio from the first microphone returned by media query using audioworklet's port.postMessage() to send it to the js thread. Then after recording plays the received samples using same sample rate as reported by the audio context used for recording.


STEPS TO REPRODUCE:
I don't have a reproducible sequence of events to lead to the issue, but it does occur frequently and seems to be easy to reproduce again and again when the correct preconditions are hit.

To try to reproduce, load the page using audioworklet for recording: https://jk.numfum.com/mic-issue/index.html 
and open https://jsfiddle.net/st___h/36w7vxn2/27/show to another tab.
See: https://jk.numfum.com/mic-issue/tabs.mov for reproduction where the fiddle is run in Version 15.6.1 (17613.3.9.1.16) and the audio worklets in Tech preview Release 151 (Safari 16.0, WebKit 17615.1.1.2)

In the jsfiddle, start playback of the audio, then in the audioworklet page, press "record", after 10 or so seconds, press "stop", close the fiddle tab, so it doesn't make any noise and on the audioworklet page press "playback".
Playing back the received samples, when the issue is reproduced, will skip 1-2 seconds every 1-2 seconds. Estimating the recorded sample rate based on the received samples and duration of recording yields roughly 25.5k, when all requested and reported sample rates are 48k. When the issue doesn't occur, the estimated sample rate is reported pretty accurately a 48k (+/-0.1k)  

See: https://jk.numfum.com/mic-issue/spotify.mov for another reproduction using spotify as audio source.



We have reproduced this on at least:
Release 151 (Safari 16.0, WebKit 17615.1.1.2) (intel)
safari Version 15.6 (17613.3.9.1.5) (m1)


Another interesting symptom when reproducing this is that when the recording is started, playback of audio _in another Safari tab/safari process_ speeds up (and changes the pitch). This seems to be reproducible almost 100% on my machine, so I don't know if the issues are related. Worth noting anyway.
As seen in the videos, when bootsrapping the microphone, the cpu usage of coreaudiod goes briefly very high. The latter of the above videos shows over 500%.


files for the test as a zip: https://jk.numfum.com/mic-issue/mic-issue.zip

-- 
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/20220822/03a3a527/attachment-0001.htm>