1473345 - Audio not heard from Firefox WebRTC at other users in Blackboard session

Status: RESOLVED FIXED

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

Description

[Abhinav Khawarey]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.42 Safari/537.36

Steps to reproduce:

1. Joined session http://bit.ly/AbhiVirtualOffice from 1 Chrome and 1 Firefox 61.0 user.
2. Started talking from the Firefox user.


Actual results:

Firefox user couldn't be heard by Chrome user.


Expected results:

Firefox user should've been heard by Chrome user.

Note: This is not an issue with Firefox 60 but can be reproduced on Firefox 61 and above versions (checked on Firefox 62 and 63)

Comment 1

[Balwant Bisht]

We seeing FF 61 sending a audio bitrate of around 18kbps to MCU regardless of audio track enabled true or false. We are not seeing any SDP change between FF 60 & FF 61.

Microphone working fine when attached to local audio element, only issue is with outgoing audio to MCU over PeerConnection. Outgoing Video to MCU and Incoming audio/video from MCU is working fine.

Comment 2

[Paul Adenot (:padenot)]

Nils, any idea on this one ?

Comment 3

[Richard Brookes-Tee]

I'm having a similar experience.  Thinking it might be related to this https://bugzilla.mozilla.org/show_bug.cgi?id=1462216.

But, I'm also thinking it could be my JS.
To which, I'm, upon creation of a connection, I'm firstly adding a data channel.
Once that's opened, I'm adding 2 transceivers, 1 for audio and 1 for video, marking both with the "inactive" direction.

Then when I want to send my audio, I'm,
taking the audio track, 
adding it to a local MediaStream object,
then replacing the track in the audio transceivers sender
setting it's direction to "sendonly"
then creating an offer, sending to the other side, getting back the answer etc.

At the other end (Chrome 67), I can see the track added without any errors, it says it's opus audio and it shows data being received, but with 0 totalAudioEnergy.

Switching back to Firefox 60, and it starts to work again.

Comment 4

[Richard Brookes-Tee]

Attachment: Firefox60 MOZ-LOG=timestamp,signaling:5,jsep:5,rtplogger:5

Comment 5

[Richard Brookes-Tee]

Attachment: Firefox63mtransport.txt MOZ-LOG=timestamp,signaling:5,jsep:5,rtplogger:5,mtransport:5

Comment 6

[Richard Brookes-Tee]

I've attached a couple of logs and comparing the logs what I'm seeing is in Chrome 60, the RTP_PACKETS looks like this

12:16:17.512  000000 90 6d 1d 2e 2d 0a ed a0 12 27 72 be be de 00 01 10 c8 00 00 68 0c 40 44 fe bf 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

They vary in length slightly, between 63 and 133, with different amounts of what looks like padding zeros.

In Chrome 63, the RTP_PACKETS look like this

12:40:58.110  000000 90 6d 60 a4 29 26 09 46 7a bd af 0b be de 00 01 10 ff 00 00 78 07 c9 79 c8 c9 57 c0 a2 12 23 fa ef 67 f3 2e 4a f7 62 0a ea e4 c5 55 4d 0f 70 8c 0d 91 a9 ad a3 ee b8 81 98 9d 3b d3 b7 a7 44 e9 00

And they are all pretty much 65 bytes and all contain the exact same payload bytes.

In 60, the 9th bit is set, but not in the 63 log.

I can see the sequence and timestamp numbers increasing in both. 

Although, I'm not sure if the payload starts at byte 13 or 17.

I'll keep digging.

Comment 7

[Richard Brookes-Tee]

The aEnabled property passed to InternalProcessAudioChunk inside MediaPipeline is set to false.

Comment 8

[Richard Brookes-Tee]

For me, it turns out that since Firefox 61, if you call replaceTrack and then set the direction (as described here in stage 3, https://blog.mozilla.org/webrtc/the-evolution-of-webrtc/#more-301), then via building and stepping through the code, it turned out that at the point when the track is replaced, it was still inactive, and the change of direction isn't now activating it.  So, changing the order of my js to set the direction and then replaceTrack fixes it for me, but I'm unsure if this is intended.

Note, this only seems to affect audio.

Comment 9

[Nils Ohlmeier [:drno]]

Looks like a potential duplicate of bug 1472321.

Comment 10

[Balwant Bisht]

We verified that microphone issue is fixed with Firefox Nightly build. Is it possible to include the fix in Firefox 61? As microphone stopped working for all our customers with Firefox 61 release and Firefox 63 will take time.

Comment 11

[Balwant Bisht]

This ticket can be closed, we verified that microphone is working fine in FF62.