Confirmed users
325
edits
Gecko:MediaStreamLatency: Difference between revisions
Jump to navigation
Jump to search
→Current State
| Line 11: | Line 11: | ||
In my example, this is 4 + 10 + 3 = 17ms. The ideal latency would be just T_mike = 4ms. | In my example, this is 4 + 10 + 3 = 17ms. The ideal latency would be just T_mike = 4ms. | ||
(Note that we are using a TrackUnion, and that will cause mic data to be delayed further if there's any buildup of data due to underruns or clockrate mismatches. {{bug|884365}} will bypass the MediaStreamGraph on the input side for any stream sourced via getUserMedia, so we should be close to T_mike (4ms).) | (Note that we are using a TrackUnion, and that will cause mic data to be delayed further if there's any buildup of data due to underruns or clockrate mismatches. {{bug|884365}} will bypass the MediaStreamGraph on the input side for any stream sourced via getUserMedia, so we should be close to T_mike (4ms). Also note that T_mike may be considerably more than 4ms; on Android it might be as much as 40ms or more. However, we have no direct control of T_mike.) | ||
On the "receive" side, at each MediaStreamGraph tick we pull the latest data from the network stack (via NotifyPull), and copy it to the end of the output nsAudioStream. The worst-case latency before data is picked up by the libcubeb callback (ignoring scheduling problems) happens when a sample has to wait T_graph for the graph to tick, then wait for graph processing, and then we append the sample to the nsAudioStream buffer and have to wait for at most T_cubeb for it to be consumed and played. (I'll ignore driver processing time, which we can't control.) | On the "receive" side, at each MediaStreamGraph tick we pull the latest data from the network stack (via NotifyPull), and copy it to the end of the output nsAudioStream. The worst-case latency before data is picked up by the libcubeb callback (ignoring scheduling problems) happens when a sample has to wait T_graph for the graph to tick, then wait for graph processing, and then we append the sample to the nsAudioStream buffer and have to wait for at most T_cubeb for it to be consumed and played. (I'll ignore driver processing time, which we can't control.) | ||
T_recv = T_graph + T_proc + T_cubeb | T_recv = T_graph + T_proc + T_cubeb | ||
In my example, this is 38ms. The ideal latency would be to pull the latest audio from the network stack in each libcubeb callback, i.e. T_cubeb = 25ms. | In my example, this is 38ms. The ideal latency would be to pull the latest audio from the network stack in each libcubeb callback, i.e. T_cubeb = 25ms. | ||
Note: There are issues with this due to the WebRTC/NetEQ API - jesup | |||
Playing an AudioBuffer has the same latency analysis. | Playing an AudioBuffer has the same latency analysis. | ||