Confirmed users
33
edits
Gecko:MediaStreamLatency: Difference between revisions
→Plan of action
| Line 81: | Line 81: | ||
Those are the things we can do to get better overall latency: | Those are the things we can do to get better overall latency: | ||
# Write a WASAPI backend for cubeb. This is needed so we can bring Windows' latency close to Linux's and Mac's. Important because most of the users are on Windows, and because our current backend, while working on every single Windows Desktop OS released after 1995, is neither CPU efficient nor low-latency capable. | |||
# Drive the MSG with the cubeb callback. This folds the MSG latency into the callback (giving us 0-10ms latency improvement). More importantly, this allows us to stop using the BufferedAudioStream that adds theoretically anywhere between 0 and 1 full second of latency, depending on how full it is. In practice, it adds as much latency as the delay between the moment the first |BufferedAudioStream::Write| and the first callback is called, because the callback is very likely to consume data as fast as it is written, otherwise the situation would not sustainable. We can get around (T_bas + T_msg)ms doing that, where T_bas is the latency of the BufferedAudioStream (around 120ms on my system when running a simple WebAudio demo, plus the 10ms of the MSG). Some open question that don't have answers yet: | |||
## How do we deal with Android having terrible latency? The callback won't get called every 10ms. Maybe we can get around that by running multiple iteration of the graph in a single callback until the frame count request for the callback is satisfied, and put the remaining frames in a little buffer. | |||
## Can something down the graph (gUM, WebRTC) block (as in, waiting on a monitor or something)? We want to avoid that. | |||
# Implement [1], so that authors can do tradeoffs between having battery life/cpu consumption/latency. We would put the same attribute on the AudioContext or something. | |||
# Figure out the correct way to have the time difference between the graph time and the audio presentation time, which would be approximately: | |||
fixed_output_latency = driver_buffer_frames * driver_buffer_number / samplerate | fixed_output_latency = driver_buffer_frames * driver_buffer_number / samplerate | ||
fwiw, some people on the webaudio mailing list requested that to have better video/audio sync [2]. | fwiw, some people on the webaudio mailing list requested that to have better video/audio sync [2]. | ||
[1]: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-April/039338.html | [1]: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-April/039338.html | ||