Closed Bug 785584 Opened 12 years ago Closed 7 years ago

(meta) WebRTC Audio latency is too high (static latency, and increases in latency)

Categories

(Core :: WebRTC: Audio/Video, defect)

Product:
Core
Component:
WebRTC: Audio/Video
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: derf, Assigned: jesup)

References

Details

(Keywords: dogfood, meta)

Attachments

(1 file, 8 obsolete files)

Example output graph
(deleted), application/pdf
Details
Testing an Opus call, the audio latency is very high (multiple seconds) after less than a minute on the call. Video latency remains sub 1 second, so this is not a networking issue. I don't know if G.711 would present a similar problem.
Blocks: 694810
Whiteboard: [WebRTC], [blocking-webrtc+]
Assigned to padenot, but I may work on it as well. This is likely largely related to mediastreams and the interface to them (clock drift and queuing of data in the graph).
Assignee: nobody → paul
Priority: -- → P1
I'm going to start by writing patches check where latency is added. Maybe someone here has a couple ideas.
Blocks: 834687
Attached patch Add a way to get cubeb latency. (obsolete) (deleted) — — Splinter Review
This patch adds a way to get the latency of the backend of cubeb. I've implemented it for alsa and audiounit (macos), because I believe it is what most of us use. I'm not too sure about the audiounit part, though.
This adds another log (MediaLog), and adds logging in a couple locations in the tree. The output can be processed by the python script included, that produces a graph. The script itself needs matplotlib. The neteq stuff stays at 0 all the time because I probably put it at the wrong location.
Attached file Example output graph (deleted) —
This is an example of the output the script can give you. This particular graph represents a gUM session, on Linux (hence the terrible cubeb latency, because Alsa over Pulseaudio).
Severity: normal → critical
Experimenting with dogfooding for 1:1 meetings today, QA definitely concluded this bug greatly impacts having an effective dogfooding strategy work well for 1:1 meetings.
Keywords: dogfood
Keywords: meta
Whiteboard: [WebRTC], [blocking-webrtc+] → [WebRTC], [blocking-webrtc-]
Depends on: 866675
We too have experienced a significant latency with audio/video. We have a consistently reproducible example of this. If anyone wants to see a demo of this latency effect, please let me know and I will send you a URL and instructions to view this.
Repurposing explicitly as the master audio latency meta bug
Assignee: paul → rjesup
Depends on: 879213, 884365, 886886
OS: Linux → All
Hardware: x86_64 → All
Summary: Audio latency is too high → (meta) WebRTC Audio latency is too high (static latency, and increases in latency)
Depends on: 901539, 901831
Attached patch Add a way to get cubeb latency. (obsolete) (deleted) — — Splinter Review
Attachment #708636 - Attachment is obsolete: true
Assignee: rjesup → snandaku
This version is verified on latest m-c on OSX. (In reply to Suhas from comment #10) > Created attachment 789084 [details] [diff] [review] > Add a way to get cubeb latency.
Attached file Part 1 - Add a way to get cubeb latency (obsolete) (deleted) —
Padenot's patch updated to latest m-c
Attachment #789084 - Attachment is obsolete: true
Attached file Part -2 Exposing audio stream latency (obsolete) (deleted) —
Patch to add latency reporting in AudioStream.
Attachment #789585 - Attachment description: cubeb-latency-report → Part 1 - Add a way to get cubeb latency
Attachment #708640 - Attachment is obsolete: true
Attachment #789590 - Attachment is patch: true
Attached file Part 5 - Content API to set the requested latency (obsolete) (deleted) —
Part 1 till Part 5 are Padenot's original latency patches that has been made to work on the latest m-c. These have been tested these patches on OSX and Windows 8.1 I can generate latency graphs once i understand the use-cases that needs to be verified to help debug this issue
Depends on: 904617
Attachment #789585 - Attachment is obsolete: true
Attachment #789585 - Attachment is patch: false
Attachment #789586 - Attachment is obsolete: true
Attachment #789586 - Attachment is patch: false
Attachment #789587 - Attachment is obsolete: true
Attachment #789587 - Attachment is patch: false
Attachment #789590 - Attachment is obsolete: true
Attachment #789590 - Attachment is patch: false
Attachment #789593 - Attachment is obsolete: true
Attachment #789593 - Attachment is patch: false
Moved all the attachments to 904617
Depends on: 907817
No longer depends on: 907817
Depends on: 908834
Depends on: 919215
Depends on: 920325
Depends on: 920328
Depends on: 920329
Assignee: snandaku → rjesup
Blocks: 970426
No longer blocks: 970426
backlog: --- → webRTC+
Rank: 14
Whiteboard: [WebRTC], [blocking-webrtc-]
This is a meta, which typically don't prioritize. We prioritize the dependent bugs (except at the very beginning - prior to bug breakdown).
backlog: webRTC+ → ---
Rank: 14
Priority: P1 → --
Do we consider this fixed? This has improved so much over the last few years that it might make sense to retire this bug and file more focused issues (this was pre-latency optimizations, and pre-MSG refactoring, and of course pre-full-duplex).
Depends on: 1370598
I'm going to close this. I know there is 1370598, but we've made it better. We still need to understand what's up.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: