Closed Bug 785584 Opened 7 years ago Closed 2 years ago

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

Categories

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

defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: derf, Assigned: jesup)

References

(Depends on 1 open bug)

Details

(Keywords: dogfood, meta)

Attachments

(1 file, 8 obsolete files)

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.
Attached patch Add a way to get cubeb latency. (obsolete) — 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
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-]
Duplicate of this bug: 867462
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) — 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.
Padenot's patch updated to latest m-c
Attachment #789084 - Attachment is obsolete: true
Attached file Part -2 Exposing audio stream latency (obsolete) —
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
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: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.