1477200 - Temporarily bump audio input and output latency on OSX as a stop-gap measure, on macbook pros

Status: RESOLVED FIXED

(Core :: WebRTC: Audio/Video, enhancement, P2)

Comment 1

[Paul Adenot (:padenot)]

Attachment: Bug 1477200 - Temporarily bump audio input and output latency on OSX as a stop-gap measure, on macbook pros.

Review commit: https://reviewboard.mozilla.org/r/258314/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/258314/

Comment 2

[Jean-Yves Avenard [:jya]]

Comment on attachment 8993614 [details]
Bug 1477200 - Temporarily bump audio input and output latency on OSX as a stop-gap measure, on macbook pros.

https://reviewboard.mozilla.org/r/258314/#review265366

::: dom/media/GraphDriver.cpp:600
(Diff revision 1)
>        if (!strncmp(model.get() + offset, "Air", 3) ||
>            isdigit(model[offset + 1])) {
>          return true;
>        }
>      }
> -    return false;
> +    return true;

can you add a comment here about the why?

Comment 3

[Andreas Pehrson [:pehrsons]]

Comment on attachment 8993614 [details]
Bug 1477200 - Temporarily bump audio input and output latency on OSX as a stop-gap measure, on macbook pros.

https://reviewboard.mozilla.org/r/258314/#review265368

I did some tracing without and with this patch on appear.in, and saw a rough 10-fold improvement in number of budget overruns. This is the reason for the r+. Please also file a followup (mentioned in comment) to tune it back down and link it to somewhere in the tree of perf improvement bugs.

Comment 4

[Alex Chronopoulos [:achronop]]

On a similar note I don't see the benefit of having the smallest possible latency for webrtc since we have to buffer 10ms of data until we pass it to the processing. Lower latency means lower budget, means more cheap iteration that will only buffer data but, in the end, the iteration that will execute the processing will have less time available for the same amount of data.

Comment 5

[Paul Adenot (:padenot)]

(In reply to Alex Chronopoulos [:achronop] from comment #4)
> On a similar note I don't see the benefit of having the smallest possible
> latency for webrtc since we have to buffer 10ms of data until we pass it to
> the processing. Lower latency means lower budget, means more cheap iteration
> that will only buffer data but, in the end, the iteration that will execute
> the processing will have less time available for the same amount of data.

This is only in the case where we're using the APM and PeerConnection, but yes. Having the fastest latency possible is very important for Web Audio use-cases.

Comment 6

[Paul Adenot (:padenot)]

Comment on attachment 8993614 [details]
Bug 1477200 - Temporarily bump audio input and output latency on OSX as a stop-gap measure, on macbook pros.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/258314/diff/1-2/

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3f95add38e74
Temporarily bump audio input and output latency on OSX as a stop-gap measure, on macbook pros. r=pehrsons

Comment 8

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/3f95add38e74