Bug 267676 – First audio stream will be silence when re-create audio with echoCancellation: false

• Component: Media
• Status: RESOLVED CONFIGURATION CHANGED

[simu]

Created attachment 469438 [details]
First audio stream will be silence when re-create audio with echoCancellation: false

Device: iPad 17.2
z

Step to reproduce this bug:

1. Create mic-audio stream and play it

```js
      let audioInput = await navigator.mediaDevices.enumerateDevices().then(devices => {
        return devices.find(device => device.kind === 'audioinput');
      });

      const stream = await navigator.mediaDevices.getUserMedia({
        audio: {
          deviceId: audioInput.deviceId
        }
      });

      audioElement.srcObject = stream;
      audioElement.play();
```

You will hear you own voice.

1. Re-create the same device Id mic-audio stream with echoCancellation: false

```js
      await navigator.mediaDevices.getUserMedia({
        audio: {
          deviceId: audioInput.deviceId,
          echoCancellation: false,
        }
      });
```

You will never hear your voice from iPad spearker.

Attachment is the minimal reproduce demo.

[Radar WebKit Bug Importer]

<rdar://problem/121577906>

[youenn fablet]

@simu, from our testing, what happens is that the first audio stream will not be silence but the audio capture level will be lower, as well as the audio rendering level.

FWIW, we do not support capturing with and without echo cancellation.
When starting capturing the second time (without echo cancellation), the first audio stream will get the same data as the new audio stream.

See https://jsfiddle.net/3z6njbvr/ for instance.

Can you describe more clearly what you are trying to achieve here?

[youenn fablet]

Additional fiddle available at https://cdpn.io/pen/debug/xxerOvd?authentication_hash=gaAeYgPYXwvA which shows that the first audio stream continues to be recorded even if we set echoCancellation: false on the second stream.

Marking as Configuration Changed.

I will tackle the potential audio volume issue found during investigation at https://bugs.webkit.org/show_bug.cgi?id=271305.