Closed Bug 1135203 Opened 7 years ago Closed 2 years ago

No audio on far end

Categories

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

x86
macOS
defect

Tracking

()

RESOLVED INCOMPLETE
Blocking Flags:

People

(Reporter: mmc, Unassigned)

Details

Attachments

(1 file)

I did a test call with jesup on my mac around 11:15 PT, trying to reproduce https://bugzilla.mozilla.org/show_bug.cgi?id=1134772. No problems were detected on jesup's end.

Immediately after I did a hello call with ekr with the same setup, and he couldn't hear me. I could hear him fine. Nothing about my setup changed.

We reverted to g+ hangouts and ekr could hear me fine.
No longer blocks: 1134772
No longer depends on: 1023947
Attached file aec_muted.tgz
These are AEC logs when ekr couldn't hear me.
Note: I could hear Monica briefly and then I plugged in headphones and could
not. However, I could hear system sounds.
Whatever problem occurred must have been at ekr's end; likely something having to do with the OS's choice of default speakers, since he indicated privately that he killed his browser (Aurora/37) and restarted it and still had the problem.  Useful test if this recurs would be https://mozilla.github.io/webrtc_landing/gum_test.html - see what the default audio device is, and if it works.
Why would the problem appear on hello but not hangouts?
I believe Chrome uses slightly different audio input code than the default in the webrtc.org codebase (though it's similar, and parts are shared like the AEC).  Also, the code for implementing getUserMedia (and how they handle permissions and defaults) is obviously different than ours.

Also, ekr was using Aurora, which is based on a webrtc code drop from earlier last year; Nightly is now based on webrtc.org branch 40 (same one Chrome 40 uses), so it's *possible* that Nightly wouldn't have had the same problem.  I wouldn't bet on that (the capture code didn't change that much IIRC), but it's possible.

Of course, knowing what they did differently that worked would certainly help as well.
The same problem recurred this morning. We have had other successful hello calls between.

It looks like the link in comment 3 does not work.
And once again, I could hear system sounds.
(In reply to [:mmc] Monica Chew (please use needinfo) from comment #6)
> The same problem recurred this morning. We have had other successful hello
> calls between.
> 
> It looks like the link in comment 3 does not work.

https://mozilla.github.io/webrtc-landing/gum_test.html

dash, not underscore -- oops.

If this happens again:
please get AEC debug logs from both ends, and about:webrtc data from both (in particular the signaling logs and the RTP data).

Then, after the call, try the link above.  (For good measure, try it now to verify)

Thanks!
I have my logs. It's clear that some audio is coming in. Of course, it could just
be silence.

A/V sync: 23 ms Jitter-buffer delay: 28 ms
Local: 09:59:25 GMT-0700 (PDT) inboundrtp SSRC: 1541357100 Received: 2130 packets (191.03 Kb) Lost: 0 Jitter: 0
(In reply to Eric Rescorla (:ekr) from comment #9)
> I have my logs. It's clear that some audio is coming in. Of course, it could
> just be silence.
> 
> A/V sync: 23 ms Jitter-buffer delay: 28 ms
> Local: 09:59:25 GMT-0700 (PDT) inboundrtp SSRC: 1541357100 Received: 2130
> packets (191.03 Kb) Lost: 0 Jitter: 0

Thanks; I presume you don't have AEC logs from your end?  If you're receiving RTP (and it appears you are), most likely it was silence coming in.  If the browser hasn't been restarted and the mic/speaker hasn't been changed, you could try gum_test.html just to verify that audio to a media element is playing (not just system sounds).

Was there a headset plug/unplug after the browser was started, and before (or during) the call?

thanks again
(In reply to Randell Jesup [:jesup] from comment #10)
> (In reply to Eric Rescorla (:ekr) from comment #9)
> > I have my logs. It's clear that some audio is coming in. Of course, it could
> > just be silence.
> > 
> > A/V sync: 23 ms Jitter-buffer delay: 28 ms
> > Local: 09:59:25 GMT-0700 (PDT) inboundrtp SSRC: 1541357100 Received: 2130
> > packets (191.03 Kb) Lost: 0 Jitter: 0
> 
> Thanks; I presume you don't have AEC logs from your end? 

Not unless they are captured automagically.

> If you're
> receiving RTP (and it appears you are), most likely it was silence coming
> in.  If the browser hasn't been restarted and the mic/speaker hasn't been
> changed, you could try gum_test.html just to verify that audio to a media
> element is playing (not just system sounds).

Well, I have unplugged and plugged in the headset a bunch of times, but
in any case gUM works fine.


> Was there a headset plug/unplug after the browser was started, and before
> (or during) the call?

No idea, sorry.

> thanks again
Going to take a look to try to reproduce the problem.
backlog: --- → webRTC+
Flags: needinfo?(jbecerra)
Priority: -- → P2
Rank: 21
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(jbecerra)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.