Bug 306950 – [WPE][WebAudio] UI thread freezes when calling `window.alert()` with an instance of `AudioContext`

• Component: WPE WebKit
• Status: RESOLVED DUPLICATE

[Loïc Le Page]

Created attachment 478248 [details]
Web page reproducing the issue

The issue is systematic and can be reproduced easily with this page:

[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]

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]

*** This bug has been marked as a duplicate of bug 302391 ***