1135203 - No audio on far end

Status: RESOLVED INCOMPLETE

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

Description

[[:mmc] Monica Chew (no longer reading bugmail)]

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.

Comment 1

[[:mmc] Monica Chew (no longer reading bugmail)]

Attachment: aec_muted.tgz

These are AEC logs when ekr couldn't hear me.

Comment 2

[Eric Rescorla (:ekr)]

Note: I could hear Monica briefly and then I plugged in headphones and could
not. However, I could hear system sounds.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

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.

Comment 4

[[:mmc] Monica Chew (no longer reading bugmail)]

Why would the problem appear on hello but not hangouts?

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

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.

Comment 6

[[:mmc] Monica Chew (no longer reading bugmail)]

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.

Comment 7

[Eric Rescorla (:ekr)]

And once again, I could hear system sounds.

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

(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!

Comment 9

[Eric Rescorla (:ekr)]

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

Comment 10

[Randell Jesup [:jesup] (needinfo me)]

(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

Comment 11

[Eric Rescorla (:ekr)]

(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

Comment 12

[juan becerra [:juanb]]

Going to take a look to try to reproduce the problem.

Comment 13

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.