The latency situation has evolved a lot since the early days, and now we need a tighter control over the latency numbers, both when getting the minimum latency supported on the current configuration and passing it when initializing a new stream. Platform APIs usually use frames, and using milliseconds in Gecko forces conversion and unnecessary rounding. Considering that having the wrong buffer size can make us not go into a mixer fast-path (for example, android is very picky about that), we should switch to using frames in: - cubeb_device_info - cubeb_get_min_latency - cubeb_stream_init

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

Comment on attachment 8772781 [details] Bug 1283020 - Update Gecko to reflect cubeb changes: use frames instead of milliseconds for latency. https://reviewboard.mozilla.org/r/65518/#review62504 Looks good, thanks! ::: dom/media/AudioStream.cpp:366 (Diff revision 1) > return NS_ERROR_FAILURE; > } > > cubeb_stream* stream = nullptr; > + /* Convert from milliseconds to frames. */ > + uint32_t latency_frames = CubebUtils::GetCubebLatency() * aParams.rate / 1000; We could add the trsform from ms to frames inside CubebUtils::GetCubebLatency method

Pushed by paul@paul.cx: https://hg.mozilla.org/integration/mozilla-inbound/rev/344300260f4c Update cubeb consumers to pass in latency in frames and not in ms. r=achronop

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/d2ba56fc82b6 because it (or bug 1285541) seems to have caused a frequent mochitest(gl) failure: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&fromchange=9f4b5bd8af0c54daafd5e19358e7871f2bd6c2c3&bugfiler&filter-searchStr=10.%20(gl

Pushed by paul@paul.cx: https://hg.mozilla.org/integration/mozilla-inbound/rev/7ba223fde0e0 Update cubeb consumers to pass in latency in frames and not in ms. r=achronop

oops, still not merged.