Re: getDisplayMedia() and system audio

If some sounds yield echo problems in use cases we want to support there
needs to be a control against it; we can't trust the user to pick the right
thing. At the same time, we should think of a solution that does not
unnecessarily limit the user's choices.

"At this stage, it seems premature to narrow things in this way."
I narrowed things down to "all audio or all audio except tab" because I
couldn't think of a compelling use case that required picking-and-choosing
audio sources and I wanted the user to be presented with a very simple
choice: *yes or no*.
That said, the important thing with excludeTabAudio is that the particular
audio source is excluded, we could leave the rest up to the UA. We don't
have to narrow things down. If audio capture of a single application is of
interest we can still allow that.

If implementation concerns (+Emircan Uysaler <emircan@google.com>) leads to
not supporting this feature in "screen" capture, only in "window" capture,
it would be up to the user agent to sort that out, and up to its picker to
not present "screen" options to the user. Solving the system-wide audio
capturing issue is not a hard requirement for the feature (though it would
be nice!).

(With regards to cross-origin iframes: I've not thought about that yet, I
want to make sure we get the use cases down first. Needs further
discussion.)

On Fri, Sep 7, 2018 at 2:28 AM Martin Thomson <martin.thomson@gmail.com>
wrote:

> On Thu, Sep 6, 2018 at 7:08 PM Henrik Boström <hbos@google.com> wrote:
> >
> > I listed some use cases and came up with a proposal, please take a look:
> > getDisplayMedia() with audio: excludeTabAudio constraint proposal
>
> To me excludeTabAudio is an entirely new feature request on top of the
> one we were already discussing).  In theory, modulo synchronization
> problems, the app could mix out anything it already has, so that's
> fine.
>
> Where I don't see this working properly is for cross-origin iframes in
> the context of delegated capabilities (the good part of feature
> policy).  That might be easy to address (disable the capability in
> that case), or not.  I don't have a good reference model for assessing
> this.
>
> The other, implied aspect of this is the simplification to just
> capture of system audio.  Despite the obvious implementation problems
> (which I don't believe to be universal), I would still prefer to leave
> this with user agents to sort out.  If they can reasonably limit
> capture to a single application, that is a valuable feature.  If they
> can't, then they need to address the UX issues and expectations (why
> is this capturing just this app, but also the audio from that app?).
> At this stage, it seems premature to narrow things in this way.
>