This vibes with something I've seen in logs but never really reflected on before now: streams start out with a volume of 1.0, which only gets changed once a stream is added to an <audio> tag. Since the streams are mixed in WebRTC before being sent along to Chrome, this means any streams that lack an <audio> tag will retain the default volume of 1.0.

Does creating an <audio> tag with autoplay=false also work to silence the unwanted stream? I expect it should, but it'd be interesting to know.

Audio elements are created with autoplay=false by default.

But, it's also possible to work around the issue by routing the second audio stream to an audio element and never calling play().

Well, yes, I meant "without playing". :)
Good, that's how I understand it. I'll take a look and see what I can come up with.

Is this related to https://crbug.com/webrtc/8730 ?
The track is not only supposed to have 0 volume, it's supposed to be in the muted state by default, and an onunmute should fire as soon as there is something to play.

Ooh, I hadn't seen that one. It's related but not the same issue. According to that bug, streams should go from muted to unmuted once data starts appearing. Even if that were the case, the problem in this bug would still happen; the stream could still be audible before being hooked up to anything.

Either of these bugs could be fixed in Chrome or WebRTC directly, I think. Just doing it in Chrome seems safer, though. Less likely to break other users.

The following revision refers to this bug:
  https://webrtc.googlesource.com/src.git/+/c66810830c8ae5e0b1eda753669c386aa39b7cb1

commit c66810830c8ae5e0b1eda753669c386aa39b7cb1
Author: Oskar Sundbom <ossu@webrtc.org>
Date: Thu Feb 22 16:02:58 2018

Maintain audio receive stream gain across recreations

When a receive stream is created its internal Channel defaults to a
gain of 1.0. If a gain has been set for the stream, but it needs to be
recreated internally, its volume will not carry over but reset to
1.0. This CL fixes that, for now. Ideally, we'd not recreate these
streams internally.

Bug:  chromium:810848 
Change-Id: Ia2ce87a39f1f4d7d3596c1b5ab256b10bdbca3c3
Reviewed-on: https://webrtc-review.googlesource.com/54402
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Commit-Queue: Oskar Sundbom <ossu@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22156}
[modify] https://crrev.com/c66810830c8ae5e0b1eda753669c386aa39b7cb1/media/engine/webrtcvoiceengine.cc

Is this finished?

Nope, not yet. There's a Chromium CL that needs landing too.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2f6ad6aecd75ca4f2e635e077ea2f4771199fd97

commit 2f6ad6aecd75ca4f2e635e077ea2f4771199fd97
Author: Oskar Sundbom <ossu@chromium.org>
Date: Mon Apr 09 12:41:08 2018

Ensure remote WebRTC streams aren't unintentionally audible

Before a stream has been added to an <audio> tag, its gain is set to
1.0. Once a stream gets attached to an <audio> tag, its volume is set
to zero until the tag starts playing. Since remote streams are mixed in
WebRTC before being passed on to Chrome, streams that haven't been added
to a tag can still be audible, if only one other stream has.

This CL attempts to fix this by setting the initial gain of WebRTC
remote streams to 0.

Bug:  chromium:810848 
Change-Id: I08b0acbd78d3f0bd06adbb70f62d42b66146a9f5
Reviewed-on: https://chromium-review.googlesource.com/925266
Commit-Queue: Oskar Sundbom <ossu@chromium.org>
Reviewed-by: Henrik Boström <hbos@chromium.org>
Reviewed-by: Tommi <tommi@chromium.org>
Reviewed-by: Harald Alvestrand <hta@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549159}
[modify] https://crrev.com/2f6ad6aecd75ca4f2e635e077ea2f4771199fd97/content/renderer/media/webrtc/mock_peer_connection_dependency_factory.cc
[modify] https://crrev.com/2f6ad6aecd75ca4f2e635e077ea2f4771199fd97/content/renderer/media/webrtc/mock_peer_connection_dependency_factory.h
[modify] https://crrev.com/2f6ad6aecd75ca4f2e635e077ea2f4771199fd97/content/renderer/media/webrtc/webrtc_media_stream_track_adapter.cc

Tried checking the issue on reported 64.0.3282.140 and on the latest 67.0.3393.0 using Ubuntu 14.04 with the below mentioned steps.
1. Launched Chrome
2. Connected two input devices with mic
      i. Headset with USB input 
     ii. Earphones with 3.5mm jack input
3. Loaded the index.html  in a new tab.
4. Inspected the page -> Console.
We observed similar console output for both the above mentioned versions. As the audio output is considered, only the "input device with USB" is giving output in both the chrome versions and no audio output is heard from other(3.5mm jack input) one. Attaching the screenshots of console output.

@Oskar Sundbom: Could you please let us know if we have missed anything in the process of verifing the issue. And also please let us know if we can use 3.5mm jack input device (with mic) for verifing.

Deleted: 810848 M64.png 202 KB

	810848 M64.png 202 KB View Download

Deleted: 810848 M67.png 215 KB

	810848 M67.png 215 KB View Download

The console output should be the same in both versions. To be able to reproduce this, you should be able to hear both inputs in M64 but only one of them in M67. As the example script just picks the first two devices (line 44), it's possible that you've another input device in there as well, which is picked over, say, the 3.5 mm input device with mic. Does that headset work in other applications (say, appr.tc if selected as the default device in Chrome)?

Line 44:
 const [a, b] = await Promise.all(audioInputs.slice(0, 2).map(getAudio));

If you want to try using device 1 and 3, I think you could change it into something like:
 const [a, nothing, b] = await Promise.all(audioInputs.slice(0, 3).map(getAudio));

for example. You'll need to find a configuration where you hear both inputs in M64 before being able to verify this bug.

Marking this as fixed since the CL in #10.