W3C home > Mailing lists > Public > public-media-capture@w3.org > August 2013

Re: Proposal for output device selection

From: Chris Wilson <cwilso@google.com>
Date: Fri, 16 Aug 2013 07:52:55 -0700
Message-ID: <CAJK2wqUbX8a_xx9Hf82u0BftsvaukQbH5BqaY+T5P42289yyxQ@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: (wrong string) ›š›˜›˜š) <tommyw@google.com>, Tommi Gunnarsson <tommi@google.com>
On Thu, Aug 15, 2013 at 7:24 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Fri, Aug 16, 2013 at 11:22 AM, Chris Wilson <cwilso@google.com> wrote:
>
>> In particular, the digital audio workstation type case - or any music app
>> that wants access to multiple hardware interfaces, like a DJ app that has a
>> cue output as well as a mains output - typically has to leave this up to
>> the user, since it's hard to semantically define the "roles" of different
>> devices (sometimes there's no semantic difference - I just have two
>> four-track interfaces, and I want to have eight tracks of output, etc.)
>>
>
> One way to address this kind of use-case might be to allow applications to
> define their own logical output devices.
> ...
> Given that, your hypothetical DJ app would be able to define logical "cue"
> and "mains" outputs, the UA would hook those up to output devices and allow
> the user to control that mapping, and the app could save and restore those
> settings and associate them with particular application-specific contexts.
> Would that help?
>

Not really, because then every user would have to mess with their in-app
configuration (to define sends, returns, different track sets they wanted),
and then go mess with their UA setup to actually define where those
"logical" devices go.  This just makes it more complex for the user and the
developer.  I really think this is just a scenario that the "logical
devices" doesn't apply to - because you would have a very hard time
semantically defining a general enough set of logical devices to apply to
any (95% case) of the studio setups out there.


> Another thing that might help is to add APIs to grab the current output
> configuration into an opaque data object which can be persistently stored
> locally (e.g. via IndexedDB), and which can be used to restore the current
> configuration, but which can't be sent anywhere.
>

Hmm.  An intriguing idea but I'm not sure how you would say "can't be sent
anywhere" - if I can get to the device, and I can access its configuration
(which I need to be able to do), I can send that data anywhere, no?

-C
Received on Friday, 16 August 2013 14:53:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:18 UTC