Revert 'refuse to open monitor inputs'

[guest271314]

Is your feature request related to a problem? Please describe.

This commit https://chromium.googlesource.com/chromium/src/+/4519c32f528e079f25cb2afc594ecf625f943782 is the source of several issues, particularly on Linux, see Issue 931749: DOMException: could not start audio source when trying to access audioinput

Describe the solution you'd like

Build Chromium with pre-4519c32f528e079f25cb2afc594ecf625f943782 source code

• media/audio/pulse/audio_manager_pulse.cc [diff]
• media/audio/pulse/audio_manager_pulse.h [diff]
• media/audio/pulse/pulse.sigs [diff]
• media/audio/pulse/pulse_input.cc [diff]
  Describe alternatives you've considered

I have created several workarounds for this issue

• https://github.com/guest271314/captureSystemAudio
• https://github.com/guest271314/setUserMediaAudioSource

Additional context

I have most recently proposed AudioOutputContext at Web Audio API v2. I have previously brought this issue to the attention of Media Capture and Streams specification and filed several specification and Chromium issues re this matter.

I am willing to do the work. What I am requesting here is a clear and concise road map for how to build Chromium with only that change (if necessary we can build the entirety of ungoogled Chromium just to change the referenced commit) reverted.

[wchen342]

Technically it shall not be hard to add a reverse patch for that commit. But is this beyond the scope? @Eloston

[guest271314]

@wchen342

Technically it shall not be hard to add a reverse patch for that commit. But is this beyond the scope? @Eloston

How could this, logically, possibly be "beyond the scope" where the name of this repository is "ungoogled-chromium"?

The developer that filed this issue https://bugs.chromium.org/p/chromium/issues/detail?id=931749 and every developer that has published at comment at that bug concurs that they want this feature, or, for the commit to be reverted. I have not read any developer in the field concur with the decision of Chrome/Chromium authors to refuse to list or capture monitor devices at getUserMedia(). Can you post evidence here where any developer in the field has agreed with that commit?

[guest271314]

@wchen342 Read OP carefully

What I am requesting here is a clear and concise road map for how to build Chromium with only that change

I ain't scurred of *oogle.

[wchen342]

1. I am not disagreeing that this commit is highly contraversal.

2. Please read carefully the objective of this project in README.

3. If you want to know how to build chormium with a patch:

• Follow instructions at https://chromium.googlesource.com/chromium/src/+/master/docs/linux/build_instructions.md until you get to Build Chromium
• Apply desired patches or manually edit the relative files
• Continue on running ninja to build

[guest271314]

I will review the contents in the linked article.

This list item applies

3. ungoogled-chromium features tweaks to enhance ... control, and transparency. However, almost all of these features must be manually activated or enabled.

If you read this bug carefully you will notice that I requested a flag be added for this functionality, where the only way possible for this reversion to be applicable is for the user to activate the flag in the lauch command, which satisfies

2. ungoogled-chromium retains the default Chromium experience as closely as possible.

As to

1. ungoogled-chromium is Google Chromium, sans dependency on Google web services.

I posit that the commit has no rational basis, thus is dependency on Google web services, in this case an unnecessary dependency on that commit, perhaps so Chromium users that do not have a microphone connected to the machine, yet nonetheless want to call getUserMedia(), for the use cases that they might have https://bugs.chromium.org/p/chromium/issues/detail?id=865799

Issue 865799 in chromium: A way for enumerateDevices() to show audiooutput devices with labels when user has no cam or mic

while attempting to close issues disclosing inclonsistencies based on the premise that it is not feasible to actually verify a default device, yet at the same time file an issue requesting a default device be listed first (see title of and use case for https://bugs.chromium.org/p/chromium/issues/detail?id=865799), which is the opposite of the reasoning claimed for attempting to close the former issue. Now, if defining default devices is not possible w3c/mediacapture-main#727

Since it is impossible to define a mechanism to determine default devices that works for all platforms and device kinds

and the inconsistencies remain, how can any default devices be identified and verified in the first place https://github.com/w3c/mediacapture-main/issues/756 to be placed at first in the list?

[wchen342]

I think you misunderstood my position.

I was only trying to decide whether "adding a fix for something Google screwed up is going outside what we are supposed to do", not "whether they actually did it right or wrong". I can see your points and I actually agree with them. However, if the fix does not fit into the project then it still needs to be implemented somewhere else.

You did bring up a good point about flags. It is probably good to add a flag for users to switch this behavior on and off. In that case I think I won't be too big a problem.

thus is dependency on Google web services, in this case an unnecessary dependency on that commit

This is not ture. A commit is not a web service. If I read the commit correctly it does not enable any comminucations between the browser and Google's servers. From my understanding the primary purpose of removing Google web services is to cut the communications between local machine and Google servers, thus protect user privacy.

[guest271314]

The flag is a reasonable request. There is no way for that commit to be applicable except for a user to affirmatively write the flag themselves at whatever code launches their Chromium or Chrome browsers.

This is not ture. A commit is not a web service.

It can be https://bugs.chromium.org/p/chromium/issues/detail?id=816095.

In this case more of a restriction imposed by the absentee web service *oogle and its derivative works Chromium and Chrome.

From my understanding the primary purpose of removing Google web services is to cut the communications between local machine and Google servers, thus protect user privacy.

Well, that is impossible. There is no such thing as "privacy" using any signal communications. A Good American. You can make that claim if you want, however, there is certainly no way for you to verify any signal communications are "secure" whatsoever, whether the machine is being used locally or not.

Now as to those restrictions on web services, for example recording audio from web sites, that is already possible. Chromium reverting refusal to capture monitor devices will not change that. Users will need to select the device in the first place, unless they have no microphones connected. In any case we can use various other means to do that GitHub Reinstates youtube-dl After RIAA’s Abuse of the DMCA (back up your own code, there is no telling when they will make up stuff in mid-stream and ban you or your code not realizing they are communicating with the expert in that domain guest271314/banned#2, that is you deal only with primary sources [Twitter actually asked for gov'ment issued ID when they banned me for no reason https://github.com/guest271314/twitter], not mere heresay, here Chromium source code and stuff you want and don't want - it is the same principle). The reasoning that capturing system audio output would be confusing to users that are expecting microphone to be captured when they have no microphones connected to the machine is a circular, without cause to try to capture microphones in the first place.

I will try to do this myself. If you make this happen as a flag, great. Carry on.

[guest271314]

@wchen342 I am looking into using Google App Engine to build Chromium with the commit reverted.

In the meantime I found Virtual microphone using GStreamer and PulseAudio, in pertinent part

Remap source

While the null sink automatically includes a "monitor" source, many programs know to exclude monitors when listing microphones. To work around that, the module-remap-source module lets us clone that source to another one not labeled as being a monitor:

pactl load-module module-remap-source \
    master=virtmic.monitor source_name=virtmic \
    source_properties=device.description=Virtual_Microphone

which provides a means to create a virtual device that Chromium lists as an input (microphone) device at enumerateDevices() and getUserMedia(), so that we can capture the monitor device in spite of Chromium source code refusing to do so. This does not break the web.

[guest271314]

@wchen342 Am interested in how you would go about meeting the requirement https://lists.w3.org/Archives/Public/public-speech-api/2017Jun/0000.html, given guest271314/SpeechSynthesisRecorder#14, https://bugs.chromium.org/p/chromium/issues/detail?id=1032815#c6, https://bugs.chromium.org/p/chromium/issues/detail?id=1114422#c9 ?

[Eloston]

@wchen342

Technically it shall not be hard to add a reverse patch for that commit. But is this beyond the scope? @Eloston

This change is pretty small, so I'm okay to add a flag for this. It is not in-line with the main objective of the project (thus it should be under patches/extra), but we welcome changes like these as long as people are willing to maintain them. If the author is not around to maintain them, we will not guarantee they will be kept across Chromium upgrades.

[PF4Public]

I hope your question(-s) has(-ve) been answered, otherwise please let us know.
Closing this issue for now.

[guest271314]

@PF4Public I solved this using Native Messaging as mentioned at OP. The quality is superior to getUserMedia(). Still this should not be a standard restriction. What is the conclusion as to my request to revert the specific commit this issue is about?

[PF4Public]

@guest271314 Eloston did a good conclusion above. This might be a candidate for ungoogled-software/contrib if someone wishes to prepare a patch for this particular case.