Bug 302391 – REGRESSION(299424@main): [GStreamer][WPE] WebAudio doesn't resume after window.alert()

• Component: Media
• Status: RESOLVED FIXED

[Pawel Lampe]

This is a regression after https://commits.webkit.org/299424@main

When window.alert() is used on WPE port along with existing WebAudio pipline, the "resume" step that is executed after actual handling of .alert() (not implemented on WPE) freezes as WebAudio pipeline cannot finish the state transition from READY to PLAYING.

The demo that reproduces problem: https://scony.github.io/web-examples/javascript/alert.html?ac=1
- expected: the counters count without any interruption.
- actual: the counters freeze after ~5s (when window.alert() is called)

I tried locally a partial reverts of https://commits.webkit.org/299424@main:
- just removing clocksync helps
- just adding queue back does not help

[Loïc Le Page]

*** Bug 306950 has been marked as a duplicate of this bug. ***

[Loïc Le Page]

Created attachment 478249 [details]
Reproduces the bug systematically

[Loïc Le Page]

When calling `window.alert()` with the WPE flavor of WebKit it is just stopping the `AudioContext` and then restarting it. So, the expected result would be to have the different counters (frames and time in seconds) keeping on running. But what we obtain is that the counters are frozen (because the UI thread is frozen) during the time spent in the web page.

If you click on "Trigger Alert" at time=3 seconds, it will be frozen during 3 seconds.
If you click on "Trigger Alert" at time=20 seconds, it will be frozen during 20 seconds.

The issue comes from the fact that when the UI thread is restarting the `AudioContext`, it is waiting synchronously for the underlying GStreamer pipeline to switch to the `Playing` state but this is not happening immediately.
The audio buffers managed by the `AudioContext` are timestamped monotonically by a dedicated thread before being pushed to the rendering pipeline. This timestamping is not reset to zero after restarting the pipeline whereas the running time of this pipeline is effectively reset to zero when passing by the `Ready` state. So, when restarting the pipeline the timestamp of the next pushed buffer is the running time of the web page (like 3 seconds or 20 seconds in the former examples), whereas the pipeline is restarting at zero and then the `clocksync` in the pipeline is waiting during all this time preventing the pipeline to pre-roll and change state.

The solution is quite easy, we just need to reset the timestamp when restarting the pipeline. It can be done using 2 different approaches:
- letting the pipeline do the timestamping itself (by enabling "do-timestamp" in the `appsrc` and setting the pushed buffers PTS to 0)
- manually reset the actual timestamping when the `AudioContext` is restarted.

[Loïc Le Page]

Pull request: https://github.com/WebKit/WebKit/pull/57861

[EWS]

Committed 307066@main (13cab9300fd6): <https://commits.webkit.org/307066@main>

Reviewed commits have been landed. Closing PR #57861 and removing active labels.

[Radar WebKit Bug Importer]

<rdar://problem/169958734>