W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > August 2020

[mediacapture-main] Implementers must not refuse to open sources set as default at the machine: "DOMException: Could not start audio source" is not in the specification (#708)

From: guest271314 via GitHub <sysbot+gh@w3.org>
Date: Sun, 02 Aug 2020 15:57:00 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issues.opened-671641298-1596383819-sysbot+gh@w3.org>
guest271314 has just created a new issue for https://github.com/w3c/mediacapture-main:

== Implementers must not refuse to open sources set as default at the machine: "DOMException: Could not start audio source" is not in the specification ==
Chromium deliberately refuses to open a [**_source_**](https://w3c.github.io/mediacapture-main/#dfn-source) which are monitor inputs at Linux per https://chromium.googlesource.com/chromium/src/+/4519c32f528e079f25cb2afc594ecf625f943782, see https://bugs.chromium.org/p/chromium/issues/detail?id=931749.

> PulseAudio: Filter out unavailable inputs and refuse to open monitor inputs

which results in this code

```
navigator.mediaDevices.getUserMedia({audio: true})
.then(stream => {
  const recorder = new MediaRecorder(stream);
  recorder.ondataavailable = e => console.log(URL.createObjectURL(e.data));
  recorder.start();
  setTimeout(_ => recorder.stop(), 30000);
}).catch(console.error);

```

throwing this exception

`DOMException: Could not start audio source`

No such error is thrown at Nightly 80 and the device set as default, listed first in the UI when the same code is run.

The problem is such a `DOMException` is not described in the specification. Nor is restricting monitor sources set as default by the user intentionally at their machine.

The specification should not care which sources the user sets at OS level. If the user sets a default source for microphone at the OS  then `getUserMedia({audio: true})` should capture that source, not throw a `DOMException` with attached message claim "Could not start source", which is simply not true, as it is possible to dynamically set the source to a monitor after `getUserMedia({audio: true})` is called using `pavucontrol` or `pavucontrol-qt` - which will result in the device that was claimed could not start being captured.

The solution is to state clearly that Implementers must not refuse to open sources set as default at OS. It is the users' prerogative which device they set as default **_source_**, not implementers, language such as 

> Implementers must not refuse to open sources set as default.

should suffice, for the ability cite the controlling specification at the above-listed bug report, indicating that behaviour is non-conformant with the specification, and must be modified to not restrict capture of the default source set by the user at their own machine.


Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/708 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 2 August 2020 15:57:02 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 2 August 2020 15:57:03 UTC