| Summary: | REGRESSION: Safari 16.2 may introduce 1 or 2 Pops once Audio Context is activated. Then it settles down. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Omer Okcuoglu <omerokcuoglu> | ||||
| Component: | Web Audio | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | NEW --- | ||||||
| Severity: | Major | CC: | cdumez, eric.carlson, jer.noble, webkit-bug-importer, youennf | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | Safari 16 | ||||||
| Hardware: | Mac (Apple Silicon) | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
Can you attach a demonstration page, rather than a recording of the problem? Unfortunately I am unable to create a demo code at the moment. However, I can address the issue further with another comparison, something I just noticed. Before this Safari update, whenever I activated the Web Audio Context with a user interaction (click), there was a slight delay compared to Chrome and Mozilla which were instantaneous. I could keep track of the lag since I was playing a sound upon activation with an accompanying animation. Now the Safari activation of Web Audio Context is as fast as other browsers, yet this improvement coincides with the bug I am facing. I hope this might give any clues about the problem. In bug 258567, Omer notes: "It is about the system Sampling Rate. Mine was set to 96kHz and switching back to 48kHz ... also solves my other previously submitted bug: https://bugs.webkit.org/show_bug.cgi?id=249970 With Safari 16.4 these pops started to happen more often rather than just the initial pops. Keeping sample rate at 48kHz has eliminated the pops too!" |
Created attachment 464267 [details] Demonstration of the Pops. There are 2 pops at the start, then it's all good. This issue is not happening on Safari 15.6.1 on Intel and as I recall I did not experience this before 16.2 on M1. Does not happen on Mozilla nor Chrome. These pops - as can be heard at the beginning of the example - mostly happens once an Audio Context is activated, following a page refresh. Happens inconsistently but a pop is guaranteed in every 3rd page refresh. Sometimes it only comes from one channel (right or left). The amount of these pops(some are lighter and smoother) never exceeded 2, then the App functions without a hick, it is as if the engine is warming up. I have added some latency to the buffer playback scheduling to make sure my code is not blocking CPU by any means but the pops persist.