If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

ScriptProcessortNode latency/delay increases and does not recover

NEW
Unassigned

Status

()

Core
Web Audio
P3
normal
Rank:
25
2 years ago
10 days ago

People

(Reporter: michalcharemza, Unassigned)

Tracking

({testcase})

47 Branch
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Created attachment 8719782 [details]
index.html

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.82 Safari/537.36

Steps to reproduce:

In Javascript

- Create an AudioContext, AudioBufferSourceNode and ScriptProcessorNode
- Connect the AudioBufferSourceNode to the ScriptProcessorNode
- Connect the ScriptProcessorNode to the destination of the AudioContext
- Add an onaudioprocess callback to the ScriptProcessorNode, that does nothing other than calculate the difference between the playbackTime of the event, and the currentTime of the AudioContext. i.e. how far in the future the audio for the current event will be played: the latency, and sets this latency as the innerHTML value of an element in the page

Also,

Occasionally (e.g. on button press) do something that blocks the main thread. For example sum the numbers 0 to 1000000000.

A simple page that does this is attached to this bug.


Actual results:

The calculated latency starts off low (~0.02 seconds on my machine), it increases every time the intensive action is performed, and it never goes down back to the original levels. On my machine summing the numbers 0 to 1000000000 5 times results in the latency going up to over 4 seconds and then never goes back down.

This happens on the latest nightly Mozilla/5.0 (Windows NT 6.3; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0


Expected results:

The latency of the onaudioprocess callback, i.e. the difference between playbackTime and currentTime, should either never go up, or go up briefly and then drop back to low levels after the intensive processing.

Running the attached page in Google Chrome, I never see the latency go up beyond ~0.04s.
(Reporter)

Comment 1

2 years ago
This seems similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1157137 , which is listed as fixed.

Comment 2

2 years ago
Not fixed. That fix they did there improved other aspects, but this problem remains.

Updated

2 years ago
Component: Untriaged → Web Audio
Product: Firefox → Core

Updated

2 years ago
Status: UNCONFIRMED → NEW
Rank: 25
Ever confirmed: true
Priority: -- → P2

Updated

2 years ago
Keywords: testcase
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.