1268503 - Process the MSG message queue more often

Status: NEW

(Core :: Audio/Video: MediaStreamGraph, defect, P3)

Description

[Paul Adenot (:padenot)]

This will make the MSG react fast to main thread changes and is good for perceived latency on Web Audio.

We should empty the message queue before each 128 frame block.

Comment 1

[Paul Adenot (:padenot)]

Attachment: DO NOT LAND hacky way of processing the queue more often

That's one way to do it (hacked up), by lying to the MSG and slicing the
callback in 128-frames iterations. The proper way would be to actually swap the
queue more often, I wonder if it would really be better.

Also, I don't know whether not doing everything by 128 sample frames blocks
when we don't have to (for example during a simple webrtc call) has a
measureable performace impact.

Comment 2

[Karl Tomlinson (:karlt)]

Given OneIteration() runs off the system audio callback, this is not going to improve latency considerably because the multiple RunMessagesInQueue() calls will all happen at roughly the same time, except in the case where the cpu thread is close to full.

Comment 3

[Paul Adenot (:padenot)]

On window, the callback is called every 10 to 20ms. This means we can roughly render 3 to 7 web audio block. If we only process the message queue once at the beginning of the callback (as we do now), any operation on the graph has the chance of being delayed a lot.

This is a big problem for start/stop of buffers and oscillators and very tightly scheduled automation ramps. Plus the event loop load is a big problem, but short of having more processes, I don't know what we can do right now.

Comment 4

[Karl Tomlinson (:karlt)]

If the message queue is processed 3 to 7 times during the callback, there will still be a 10 to 20 ms delay before it is next processed.

Increasing the frequency of the callback would reduce the latency, but I don't know whether that approach is desirable.

The other big contributor to apparent latency is receiving updates on the main thread from the MSG.  bug 956574 comment 23 can address that side.

Tight ramps are broken by design (bug 1228207).

Comment 5

[Paul Adenot (:padenot)]

(In reply to Karl Tomlinson (ni?:karlt) from comment #4)
> If the message queue is processed 3 to 7 times during the callback, there
> will still be a 10 to 20 ms delay before it is next processed.

We have to take into account that there is 10 to 20ms between callback calls, not between callback call and return. If the processing is very light, and we spend, say, 3ms processing, with a, say, 10ms buffer size, we process three blocks, so we can react every 1ms for 3ms, and then we can't react for 7ms until the next callback.

If there is a bit more load, say we're processing for 7ms for 10ms of buffer size, we can process incoming message very often most of the time.

> Increasing the frequency of the callback would reduce the latency, but I
> don't know whether that approach is desirable.

I believe we're at the minimum on every platform except maybe for OSX and some configuration of Linux (that I just made better a couple days ago).

> The other big contributor to apparent latency is receiving updates on the
> main thread from the MSG.  bug 956574 comment 23 can address that side.

I think we indeed need to rework the clock code in some way, but I don't know yet what to do.

> Tight ramps are broken by design (bug 1228207).

They would be handled better, but I agree, yes.

Comment 6

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.