Make fitness distance a SHOULD instead of MAY on device selection, …

[jan-ivar]

Fixes #735.

…with allowance for user preference.

[guest271314]

Once selected, the source of the {{MediaStreamTrack}} MUST NOT change.

{{MediaStreamTrack}} MUST NOT change.

is not really possible to enforce from the specification, and should not be specified anyway, as that takes away any control the user has over determining which devices at their own system they capture. To overcome Chromium refusal to list and capture monitor devices at Linux it is possible to utilize pavucontrol to dynamically switch devices during capture from either Chromium input or Nightly audio callback driver input. That is a feature that should be specified here, rather than attempt to restricted as must not happen.

[guest271314]

Technically the stream is moved between devices by

pactl move-source-output is the command to move capture streams ("source output" means capture stream and "sink input" means playback stream).

https://gitlab.freedesktop.org/pulseaudio/pavucontrol/-/issues/91#note_590795.

What it appears you are trying to do will first require creating some form of initial consistency between browsers, so that they select the same default devices by default, which does not occur now. When the issue of compatibility and interoperability arise, that is where the rubber meets the road, as them old folks say.

For example, Firefox does correctly list monitor devices, as those devices are inputs. Chromium does not. To work around that one option is to stream monitor devices from Firefox to Chromium using WebRTC, among other workarounds, when we should just be able to perform the same or similar tasks at each browser, without undue restrictions.

Now, have filed multiple issues at this repository to include language that officially supports capture of monitor devices at Linux, or, if preferred, system audio output. The resounding response has been, essentially, "No". The is fine, as am well suiting to achieving requirements not officially supported by specification or implementation.

The ambiguity becomes apparent when stating, o.k., you do not support capture of speakers or headphones, why is "audiooutput" in this specification at all? Which leads to confusion for those users in the field that take the definition literally and happen to be actually trying to capture audio output to speakers and headphones. Then the problem is attempted to be deferred to Audio Output Devices API, where the term of art "audiooutput" is still not applicable, as that specification does not define capture of speakers or headphones either. Thus, if you really do not want or intend to capture headphones or speakers, remove that suggestive language from your specification, and tell those users that you are concerned about in the filed that "audiooutput" is a misnomer that does not intend to convey that capture of speakers or headphones is possible. However, as yet, none of the authors of that language have notified users in the field at large https://stackoverflow.com/a/45003549 that their efforts to capture headphones and speakers are for naught, #720, or at least include a conspicuous note stating the same, as it is reasonable to take the current definition of "audiooutput" literally, and as Chromium is the only implementation that defines that label, users will try at tht browser, to no avail.

In summary, there are many inconsistencies between implementations, and several outright ambiguities and language that when tested in the field does not produce expected results. Once you begin this procecure of trying to align consistency, if the motivation of this PR is really "Sites" then the users of those sites should be heard, clearly.

[jan-ivar]

TPAC consensus was to merge this PR and deal with any PTZ exceptions in image capture.

From minutes: "PR looks fine, but there are cases with PTZ where this may not work ... the goal is to clarify our intent that this is what ought to be done"