Per comment here: https://phabricator.services.mozilla.com/D123840?id=478060#inline-707634, when AudioCallbackDriver::mBuffer::Available() returns 0, the MTG should be iterated by 0 frame.

In bug 1654112 there is D102650 that does exactly this. It was paired with D102578 which is essentially an alternative solution to D123840, but with the guarantees discussed there.

D102578 ended up not landing on elm because it conflicted with D123840 during a rebase. I'll look into incorporating it into this bug instead.

The new AudioProcessingImpl, and in particular AEC3 it seems, is more picky on
the ordering here. After an ApplyConfig() it needs ProcessStream() to properly
set up its internals. ProcessReverseStream sets off various asserts, for
instance because the processing sample rate is not divisible by 16k if
ProcessReverseStream() was fed 44.1k.

This patch defers the parameters passed by NotifyInputData so they can be
processed during ProcessInput, which is after ControlMessages have run.
The lifetime of these parameters, in particular the buffer, is guaranteed by
AudioCallbackDriver.

We can revisit this when bug 1741959 is done.

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:pehrsons, could you have a look please?
For more information, please visit auto_nag documentation.

With the work Chun-Min is doing on decoupling the input from audio processing (this is going from 1 joint track to 2 separate ones) we'll be getting the gist of D102578 for free. It comes naturally since the audio processing track won't have a NotifyInputData.

And since bug 1654112 we are already iterating the graph on every callback, which was the main point of this bug.