1,295
edits
Gecko:MediaStreamLatency: Difference between revisions
Jump to navigation
Jump to search
→Current State
No edit summary |
|||
| 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. | ||
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 | 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. | ||