Bug 226807 - [GStreamer] imported/w3c/web-platform-tests/webaudio/the-audio-api/the-audiocontext-interface/processing-after-resume.https.html is failing
Summary: [GStreamer] imported/w3c/web-platform-tests/webaudio/the-audio-api/the-audioc...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-06-09 00:32 PDT by Diego Pino
Modified: 2023-06-25 19:30 PDT (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Diego Pino 2021-06-09 00:32:48 PDT 
This test has been consistently failing in the GTK post-commit bot for the last 4000 revisions. Before it was marked as flakey.

Diff:

--- /home/buildbot/worker/gtk-linux-64-release-tests/build/layout-test-results/imported/w3c/web-platform-tests/webaudio/the-audio-api/the-audiocontext-interface/processing-after-resume.https-expected.txt
+++ /home/buildbot/worker/gtk-linux-64-release-tests/build/layout-test-results/imported/w3c/web-platform-tests/webaudio/the-audio-api/the-audiocontext-interface/processing-after-resume.https-actual.txt
@@ -1,3 +1,3 @@
 
-PASS Test consistency of processing after resume()
+FAIL Test consistency of processing after resume() assert_equals: construct time before resume expected 0.06965986394557823 but got 0.07546485260770976
Comment 1 Philippe Normand 2021-06-14 09:07:53 PDT 
That's a consequence of not setting the AudioWorklet thread priority to RT, I think. See https://bugs.webkit.org/show_bug.cgi?id=220115
Comment 2 Diego Pino 2023-06-25 19:30:34 PDT 
This test has improved since the interval 263485@main-263492@main, probably due to https://commits.webkit.org/263490@main.

However the test is now a flakey timeout, specially in the case of WPE.