Audio during WebRTC call from one window to another doesn't work

RESOLVED INVALID

Status

()

Core
WebRTC: Audio/Video
RESOLVED INVALID
8 months ago
8 months ago

People

(Reporter: Nazar Mokrynskyi, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [needinfo to reporter 2017-05-24] )

(Reporter)

Description

8 months ago
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170523100217

Steps to reproduce:

1. Open 2 windows
2. Initiate one-way call from tab 1 to tab 2


Actual results:

In tab 2 I can see audio/video element and that it works (I see seconds counting on corresponding element and corresponding icon after tab's title), but there is no actual sound heard. When second tab is Chromium I can hear myself without issues.


Expected results:

Sound should be heard in tab 2, it seems that echo cancellation of some sort is involved in browser instance globally, which is not an expected behavior (I'm doing such calls for debugging purposes).

Updated

8 months ago
Component: Untriaged → WebRTC: Audio/Video
Product: Firefox → Core
Audio feedback is usually considered a bug, not the other way around! Firefox's echo cancellation is superior to Chrome's in my personal opinion. That said, you SHOULD hear sound e.g. if you talk, it just shouldn't feedback into the mic as easily.

Do you have steps to reproduce?

Also, do me a favor and try first opening https://jsfiddle.net/jib1/t5v3xdur/ in two tabs in Firefox, and then click the [Call] button in one of them. They should connect. Use a headset if you have one, then speak. Do you hear anything? Do you see any movement in the audio spectrum analyzer in the receiving tab?
Flags: needinfo?(nazar)
Whiteboard: [needinfo to reporter 2017-05-24]
(Reporter)

Comment 2

8 months ago
From the link you've provided (had to remove video since I don't have a web cam) I can hear myself in source tab, but not in receiving tab and there is no movement there too (but there is a speaker icon after tab title and 2 rectangles o the page).
And yes, I'm using a headset.

My OS is Ubuntu 17.10 x64 and I'm on latest nightly as of right now.
Flags: needinfo?(nazar)
I've updated the fiddle to audio-only and removed local audio playback to avoid confusion: https://jsfiddle.net/jib1/t5v3xdur/

Could you try it again to rule out typos?
Flags: needinfo?(nazar)
(Reporter)

Comment 4

8 months ago
Behavior is exactly the same: no sound heard (at all this time) and no motion.
Flags: needinfo?(nazar)
Simplifying the STRs to a single tab... How about now? https://jsfiddle.net/jib1/w02cur8z/

Sorry for pestering, this I can't reproduce on Nightly on OSX. If anyone else with linux can configm this I'd appreciate it.
Flags: needinfo?(nazar)
(Reporter)

Comment 6

8 months ago
Same story.
I've made some more testing:
- in VM with Windows 8.1 both stable and nightly work fine
- fresh profile with nightly or stable under Linux works fine
- I only seem have issue with my current profile, even when booted in safe mode

I've tried setting privacy.resistFingerprinting to `false` (had `true` before), but it didn't change anything. Could you suggest any other options I might check as well?
Flags: needinfo?(nazar)
Try going to about:support with a good and a bad profile and compare what's under "Important Modified Preferences". If anything is different, feel free to post it here.
Also check out "Multiprocess Windows" under "Application basics".
(Reporter)

Comment 9

8 months ago
E10s was fine, the option that breaks demo is `media.peerconnection.ice.no_host` set to `true`. I was able to also reproduce this issue under VM with Windows 8.1.
That's to be expected, since the fiddle provides no ice servers. Workaround: http://jsfiddle.net/jib1/w02cur8z/

From https://wiki.mozilla.org/Media/WebRTC/Privacy:

  media.peerconnection.ice.no_host -- boolean (default false) -- eliminate all local addresses from the candidates (Firefox 51)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 months ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.