Update audio api to use v2 stable device ID

Update audio api to use v2 stable device ID

Algorithm used to calculate stable audio device ID has been updated
in cras to better distinguish instances of identical USB devcies.
This exposes the new stable device ID to audio API.
The existing stableDeviceId does not to be currently used, so it
should be OK just to overwrite it.

BUG=661861
Review-Url: https://codereview.chromium.org/2585413002
Cr-Commit-Position: refs/heads/master@{#444221}
Committed: https://chromium.googlesource.com/chromium/src/+/4e3e93214f404cd6f3da984000a447d8284cf828

[tbarzic, 2016-12-19 23:06:45]

tbarzic@chromium.org changed reviewers:
+ jennyz@chromium.org, rdevlin.cronin@chromium.org, steel@chromium.org

[tbarzic, 2016-12-19 23:06:45]

Jenny, can you please take a look.

rdevlin.cronin and steel for OWNER reviews

[tbarzic, 2016-12-19 23:34:23]

tbarzic@chromium.org changed reviewers:
- steel@chromium.org

[tbarzic, 2016-12-19 23:34:24]

removing steel, as I'll be added to api/audio/OWNERS

[Devlin, 2016-12-20 18:15:45]

https://codereview.chromium.org/2585413002/diff/1/extensions/common/api/audio...
File extensions/common/api/audio.idl (right):

https://codereview.chromium.org/2585413002/diff/1/extensions/common/api/audio...
extensions/common/api/audio.idl:56: DOMString stableId;
This is kind of a shame - we now have 3 different ids on this single object.  Is
there no way we can do this opaquely to the developer?

[tbarzic, 2016-12-20 18:51:20]

https://codereview.chromium.org/2585413002/diff/1/extensions/common/api/audio...
File extensions/common/api/audio.idl (right):

https://codereview.chromium.org/2585413002/diff/1/extensions/common/api/audio...
extensions/common/api/audio.idl:56: DOMString stableId;
On 2016/12/20 18:15:45, Devlin wrote:
> This is kind of a shame - we now have 3 different ids on this single object. 
Is
> there no way we can do this opaquely to the developer?

I guess we could, but at cost of the app losing information previously saved in
their storage (which was the goal of introducing stableDeviceId in the first
place).

Note that this API is still in dev, and currently used by a single app. I plan
to expose deprecated stableDeviceId only to the current whitelist, and
eventually remove it altogether.

[Devlin, 2016-12-20 19:36:17]

https://codereview.chromium.org/2585413002/diff/1/extensions/common/api/audio...
File extensions/common/api/audio.idl (right):

https://codereview.chromium.org/2585413002/diff/1/extensions/common/api/audio...
extensions/common/api/audio.idl:56: DOMString stableId;
On 2016/12/20 18:51:20, tbarzic wrote:
> On 2016/12/20 18:15:45, Devlin wrote:
> > This is kind of a shame - we now have 3 different ids on this single object.

> Is
> > there no way we can do this opaquely to the developer?
> 
> I guess we could, but at cost of the app losing information previously saved
in
> their storage (which was the goal of introducing stableDeviceId in the first
> place).
> 
> Note that this API is still in dev, and currently used by a single app. I plan
> to expose deprecated stableDeviceId only to the current whitelist, and
> eventually remove it altogether.

That makes it better.  If that's the case, can we just reach out to that app and
say "by the way, this is gone"?  Or do we really need this transition period?

[tbarzic, 2016-12-20 19:53:55]

tbarzic@chromium.org changed reviewers:
+ mnilsson@chromium.org

[tbarzic, 2016-12-20 19:53:56]

+mnilsson for the question about current stable ID usage.

https://codereview.chromium.org/2585413002/diff/1/extensions/common/api/audio...
File extensions/common/api/audio.idl (right):

https://codereview.chromium.org/2585413002/diff/1/extensions/common/api/audio...
extensions/common/api/audio.idl:56: DOMString stableId;
On 2016/12/20 19:36:17, Devlin wrote:
> On 2016/12/20 18:51:20, tbarzic wrote:
> > On 2016/12/20 18:15:45, Devlin wrote:
> > > This is kind of a shame - we now have 3 different ids on this single
object.
> 
> > Is
> > > there no way we can do this opaquely to the developer?
> > 
> > I guess we could, but at cost of the app losing information previously saved
> in
> > their storage (which was the goal of introducing stableDeviceId in the first
> > place).
> > 
> > Note that this API is still in dev, and currently used by a single app. I
plan
> > to expose deprecated stableDeviceId only to the current whitelist, and
> > eventually remove it altogether.
> 
> That makes it better.  If that's the case, can we just reach out to that app
and
> say "by the way, this is gone"?  Or do we really need this transition period?

We could, but imho it would be better to provide the app a chance to update
their stored mapping from stableDeviceId to device properties.

Adding +mnilsson to check if we could get away with just replacing stable IDs
(without providing a transitional period where both deprecated and new stable ID
are exposed).

[chromium-reviews, 2016-12-21 23:14:41]

As far as cfm is concerned, it should be safe to replace the old stable ID
with a new one that works. Cfm never used the old one because it didn't
offer a significant edge over an heuristic based on the other components of
the device name. A truly stable ID will be awesome.

Regular chrome OS non-kiosk mode may or may not use it for device
persisting, I don't know.

Jenny, do you know?

On Dec 20, 2016 8:53 PM, <tbarzic@chromium.org> wrote:

> +mnilsson for the question about current stable ID usage.
>
>
> https://codereview.chromium.org/2585413002/diff/1/
> extensions/common/api/audio.idl
> File extensions/common/api/audio.idl (right):
>
> https://codereview.chromium.org/2585413002/diff/1/
> extensions/common/api/audio.idl#newcode56
> extensions/common/api/audio.idl:56: DOMString stableId;
> On 2016/12/20 19:36:17, Devlin wrote:
> > On 2016/12/20 18:51:20, tbarzic wrote:
> > > On 2016/12/20 18:15:45, Devlin wrote:
> > > > This is kind of a shame - we now have 3 different ids on this
> single object.
> >
> > > Is
> > > > there no way we can do this opaquely to the developer?
> > >
> > > I guess we could, but at cost of the app losing information
> previously saved
> > in
> > > their storage (which was the goal of introducing stableDeviceId in
> the first
> > > place).
> > >
> > > Note that this API is still in dev, and currently used by a single
> app. I plan
> > > to expose deprecated stableDeviceId only to the current whitelist,
> and
> > > eventually remove it altogether.
> >
> > That makes it better. If that's the case, can we just reach out to
> that app and
> > say "by the way, this is gone"? Or do we really need this transition
> period?
>
> We could, but imho it would be better to provide the app a chance to
> update their stored mapping from stableDeviceId to device properties.
>
> Adding +mnilsson to check if we could get away with just replacing
> stable IDs (without providing a transitional period where both
> deprecated and new stable ID are exposed).
>
> https://codereview.chromium.org/2585413002/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[tbarzic, 2016-12-22 01:17:24]

On 2016/12/21 23:14:41, chromium-reviews wrote:
> As far as cfm is concerned, it should be safe to replace the old stable ID
> with a new one that works. Cfm never used the old one because it didn't
> offer a significant edge over an heuristic based on the other components of
> the device name. A truly stable ID will be awesome.
> 
> Regular chrome OS non-kiosk mode may or may not use it for device
> persisting, I don't know.
> 
> Jenny, do you know?
> 

Regular Chrome OS does use the ID for persisting device settings, but that's
been handled :)
My only concern was with using the stable ID through chrome.audio API.

> On Dec 20, 2016 8:53 PM, <mailto:tbarzic@chromium.org> wrote:
> 
> > +mnilsson for the question about current stable ID usage.
> >
> >
> > https://codereview.chromium.org/2585413002/diff/1/
> > extensions/common/api/audio.idl
> > File extensions/common/api/audio.idl (right):
> >
> > https://codereview.chromium.org/2585413002/diff/1/
> > extensions/common/api/audio.idl#newcode56
> > extensions/common/api/audio.idl:56: DOMString stableId;
> > On 2016/12/20 19:36:17, Devlin wrote:
> > > On 2016/12/20 18:51:20, tbarzic wrote:
> > > > On 2016/12/20 18:15:45, Devlin wrote:
> > > > > This is kind of a shame - we now have 3 different ids on this
> > single object.
> > >
> > > > Is
> > > > > there no way we can do this opaquely to the developer?
> > > >
> > > > I guess we could, but at cost of the app losing information
> > previously saved
> > > in
> > > > their storage (which was the goal of introducing stableDeviceId in
> > the first
> > > > place).
> > > >
> > > > Note that this API is still in dev, and currently used by a single
> > app. I plan
> > > > to expose deprecated stableDeviceId only to the current whitelist,
> > and
> > > > eventually remove it altogether.
> > >
> > > That makes it better. If that's the case, can we just reach out to
> > that app and
> > > say "by the way, this is gone"? Or do we really need this transition
> > period?
> >
> > We could, but imho it would be better to provide the app a chance to
> > update their stored mapping from stableDeviceId to device properties.
> >
> > Adding +mnilsson to check if we could get away with just replacing
> > stable IDs (without providing a transitional period where both
> > deprecated and new stable ID are exposed).
> >
> > https://codereview.chromium.org/2585413002/
> >
> 
> -- 
> You received this message because you are subscribed to the Google Groups
> "Chromium-reviews" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:chromium-reviews+unsubscribe@chromium.org.

[tbarzic, 2016-12-22 02:03:23]

Description was changed from

==========
Introduce v2 stable device ID to audio API

Algorithm used to calculate stable audio device ID has been updated
in cras to better distinguish instances of identical USB devcies.
This exposes the new stable device ID to audio API.
The ID is exposed as part of AudioDeviceProperties via a new property
|stableId|. The deprecated stable device ID will remain exposed via
old, |stableDeviceId| property - so current clients can migrate
to new stable device ID without losing persisted data (potentially
mapped using stableDeviceId).

BUG=673392
==========

to

==========
Update audio api to use v2 stable device ID

Algorithm used to calculate stable audio device ID has been updated
in cras to better distinguish instances of identical USB devcies.
This exposes the new stable device ID to audio API.
The existing stableDeviceId does not to be currently used, so it
should be OK just to overwrite it.

BUG=673392
==========

[tbarzic, 2017-01-11 17:54:51]

tbarzic@chromium.org changed reviewers:
- rdevlin.cronin@chromium.org

[tbarzic, 2017-01-11 17:54:52]

Jenny, can you please take a look.

removing Devlin from the review - no need for audio.idl review anymore

[jennyz, 2017-01-12 01:07:27]

The bug attached to this cl includes several different tasks, can you file
separate bugs for each task? This way, it is easier to track the particular task
and its cls.

[tbarzic, 2017-01-12 01:36:18]

Description was changed from

==========
Update audio api to use v2 stable device ID

Algorithm used to calculate stable audio device ID has been updated
in cras to better distinguish instances of identical USB devcies.
This exposes the new stable device ID to audio API.
The existing stableDeviceId does not to be currently used, so it
should be OK just to overwrite it.

BUG=673392
==========

to

==========
Update audio api to use v2 stable device ID

Algorithm used to calculate stable audio device ID has been updated
in cras to better distinguish instances of identical USB devcies.
This exposes the new stable device ID to audio API.
The existing stableDeviceId does not to be currently used, so it
should be OK just to overwrite it.

BUG=661861
==========

[tbarzic, 2017-01-12 01:39:05]

On 2017/01/12 01:07:27, jennyz wrote:
> The bug attached to this cl includes several different tasks, can you file
> separate bugs for each task? This way, it is easier to track the particular
task
> and its cls.

OK, I'll add more granular issues, but I think it would make sense to bundle
this CL with updating algorithm for calculating audio device stable ID.

[jennyz, 2017-01-18 00:04:34]

lgtm

[tbarzic, 2017-01-18 00:05:33]

The CQ bit was checked by tbarzic@chromium.org

[commit-bot: I haz the power, 2017-01-18 00:06:32]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-18 01:18:27]

CQ is committing da patch.

Bot data: {"patchset_id": 40001, "attempt_start_ts": 1484697933742580,
"parent_rev": "8d5cc8ffcea0e15d854736fe2a5c945924591c88", "commit_rev":
"4e3e93214f404cd6f3da984000a447d8284cf828"}

[commit-bot: I haz the power, 2017-01-18 01:19:42]

Description was changed from

==========
Update audio api to use v2 stable device ID

Algorithm used to calculate stable audio device ID has been updated
in cras to better distinguish instances of identical USB devcies.
This exposes the new stable device ID to audio API.
The existing stableDeviceId does not to be currently used, so it
should be OK just to overwrite it.

BUG=661861
==========

to

==========
Update audio api to use v2 stable device ID

Algorithm used to calculate stable audio device ID has been updated
in cras to better distinguish instances of identical USB devcies.
This exposes the new stable device ID to audio API.
The existing stableDeviceId does not to be currently used, so it
should be OK just to overwrite it.

BUG=661861

Review-Url: https://codereview.chromium.org/2585413002
Cr-Commit-Position: refs/heads/master@{#444221}
Committed:
https://chromium.googlesource.com/chromium/src/+/4e3e93214f404cd6f3da984000a4...
==========

[commit-bot: I haz the power, 2017-01-18 01:19:43]

Committed patchset #3 (id:40001) as
https://chromium.googlesource.com/chromium/src/+/4e3e93214f404cd6f3da984000a4...