Intent to Deprecate and Remove: WebAudio Media nodes from OfflineAudioContext

[Raymond Toy]

Primary eng (and PM) emails

rt...@chromium.org, hong...@chromium.org

Summary

The WebAudio MediaElementAudioSourceNode, MediaStreamAudioSourceNode, and MediaStreamAudioDestinationNode will only be allowed to be created on an AudioContext, not OfflineAudioContext.

Motivation

The nodes listed above are inherently real-time audio nodes that assume things progress in a real-time manner.  But an OfflineAudioContext is specifically designed not to be constrained by real-time processing and is intended to run faster than real-time when possible.  These two constraints are incompatible so these nodes will no longer be allowed to work for an OfflineAudioContext. They will, however, continue to be created for an AudioContext, which produces real-time audio.

In recognition of this fact the WebAudio specification removed these nodes from an OfflineAudioContext in 2015.

Interoperability and Compatibility Risk

It’s not clear how much we will break in removing this since there are no use counters for this case.  The usage of these nodes in general is relatively low. We take it as a good sign that Firefox has already removed these and there have been no bugs filed on this that we know of.  However, see also the WebAudio spec issue 1605.

Edge: Currently allows offline audio context

Firefox: Already removed

Safari: Currently allows offline audio context.

Alternative implementation suggestion for web developers

There is no drop-in alternative, but it can be approximated by using an AudioContext and a ScriptProcessorNode or AudioWorkletNode to capture the data from the Media node.

Usage information from UseCounter

There are use counters for these nodes, but they don’t distinguish between whether an OfflineAudioContext or AudioContext is used.  We will add use counters for this to measure how often these are used with an OfflineAudioContext.

Current counters are:

• MediaElementAudioSourceNode

• https://www.chromestatus.com/metrics/feature/timeline/popularity/640

• https://www.chromestatus.com/metrics/feature/timeline/popularity/1716

• MediaStreamAudioSourceNode

• https://www.chromestatus.com/metrics/feature/timeline/popularity/642

• https://www.chromestatus.com/metrics/feature/timeline/popularity/1717

• MediaStreamAudioDestinationNode

• https://www.chromestatus.com/metrics/feature/timeline/popularity/641

• https://www.chromestatus.com/metrics/feature/timeline/popularity/1702

Entry on the feature dashboard

https://www.chromestatus.com/features/5258622686724096

Requesting approval to remove too?

Yes.  We will tentatively remove this no earlier than M70, depending on the use counter data. If the usage is high, we may postpone removal until a later date to allow developers to update their code.

[Raymond Toy]

Quick clarification:

On Thu, Jun 7, 2018 at 11:15 AM Raymond Toy <rt...@chromium.org> wrote:

Interoperability and Compatibility Risk

It’s not clear how much we will break in removing this since there are no use counters for this case. 

By "this case", I meant no counters to show if these nodes are used with an OfflineAudioContext. 

[Chris Harrelson]

LGTM1 to deprecate and try to remove in M70. Please come back with stable channel use counter data on M69 to confirm.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE3TgXFfTai65K0WPUR6%3DNpuZ%3D3h-%3DS8%2BF8WsP%3DYVY0s6CJj%2Bw%40mail.gmail.com.

[TAMURA, Kent]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-i8J6k72f04LAy38VUjM-X%2Bkjr2z6vYOHv_hA%3DOrhjbg%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

[Philip Jägenstedt]

Hey Raymond,

I'm fairly sure that MediaStreamAudioSourceNode is used for the "mike check" of WebRTC web apps like Hangouts and Meet, although perhaps not together with OfflineAudioContext. Nevertheless, do you have a more fleshed out example using AudioWorkletNode that would replace existing use of OfflineAudioContext?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqHByM1qyBc0%2B1iAeBQsMTp1_h9C_G1K%2BVwMJbjAYyispg%40mail.gmail.com.

[Harald Alvestrand]

One of the attempts to work around the autoplay issue for the "mike check" of WebRTC applications while we had the autoplay imbroglio used OfflineAudioNode.

We should install an use counter to verify that none of the production services picked up on this workaround and deployed it.

M70 is the same version as the target date for reintroducing the autoplay denial for WebAudio.

On Mon, Jun 11, 2018 at 12:18 PM, 'Philip Jägenstedt' via blink-dev <blin...@chromium.org> wrote:

Hey Raymond,

I'm fairly sure that MediaStreamAudioSourceNode is used for the "mike check" of WebRTC web apps like Hangouts and Meet, although perhaps not together with OfflineAudioContext. Nevertheless, do you have a more fleshed out example using AudioWorkletNode that would replace existing use of OfflineAudioContext?

On Fri, Jun 8, 2018 at 1:27 AM TAMURA, Kent <tk...@chromium.org> wrote:

LGTM2

On Fri, Jun 8, 2018 at 3:34 AM Chris Harrelson <chri...@chromium.org> wrote:

LGTM1 to deprecate and try to remove in M70. Please come back with stable channel use counter data on M69 to confirm.

On Thu, Jun 7, 2018 at 11:22 AM Raymond Toy <rt...@chromium.org> wrote:

Quick clarification:

On Thu, Jun 7, 2018 at 11:15 AM Raymond Toy <rt...@chromium.org> wrote:

Interoperability and Compatibility Risk

It’s not clear how much we will break in removing this since there are no use counters for this case. 

By "this case", I meant no counters to show if these nodes are used with an OfflineAudioContext. 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE3TgXFfTai65K0WPUR6%3DNpuZ%3D3h-%3DS8%2BF8WsP%3DYVY0s6CJj%2Bw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-i8J6k72f04LAy38VUjM-X%2Bkjr2z6vYOHv_hA%3DOrhjbg%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqHByM1qyBc0%2B1iAeBQsMTp1_h9C_G1K%2BVwMJbjAYyispg%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYf%3DU2tZ8Yxh5dRtWgpz1GhAWfxnC9XiVH%2BXQDj%3DpnH7TA%40mail.gmail.com.

[Raymond Toy]

On Mon, Jun 11, 2018 at 3:18 AM Philip Jägenstedt <foo...@google.com> wrote:

Hey Raymond,

I'm fairly sure that MediaStreamAudioSourceNode is used for the "mike check" of WebRTC web apps like Hangouts and Meet, although perhaps not together with OfflineAudioContext. Nevertheless, do you have a more fleshed out example using AudioWorkletNode that would replace existing use of OfflineAudioContext?

Yes, it's used for a volume meter.  And the use of the OfflineAudioContext was a way to work around the new WebAudio autoplay restriction policy that recently landed and also recently reverted to be relanded in M70.

I think that particular issue (autoplay restrictions) might get solved in a different way. (Don't want to go into details because it's not decided yet.)

As for a solution, no, I don't have a full replacement.  My idea was just to use an AudioContext to do the measurements.  It's not really possible to fake an OfflineAudioContext if you're expecting faster-than-realtime processing.  If you don't need that, then an AudioContext is the way to go, and you can use an AudioWorklet or ScriptProcessor to capture the data that an OfflineAudioContext would return.  But that's not needed for a volume meter---just use an AudioContext.

[Raymond Toy]

On Mon, Jun 11, 2018 at 4:23 AM Harald Alvestrand <h...@google.com> wrote:

One of the attempts to work around the autoplay issue for the "mike check" of WebRTC applications while we had the autoplay imbroglio used OfflineAudioNode.

We should install an use counter to verify that none of the production services picked up on this workaround and deployed it.

I'm adding usecounters now.  It won't tell you if it's for WebRTC, but we'll at least know how common this is. 

M70 is the same version as the target date for reintroducing the autoplay denial for WebAudio.

I randomly picked M70 since 67 just recently landed.  We can postpone it, but since the autoplay restrictions are coming back in M70, this seemed like a good time. 

On Mon, Jun 11, 2018 at 12:18 PM, 'Philip Jägenstedt' via blink-dev <blin...@chromium.org> wrote:

Hey Raymond,

I'm fairly sure that MediaStreamAudioSourceNode is used for the "mike check" of WebRTC web apps like Hangouts and Meet, although perhaps not together with OfflineAudioContext. Nevertheless, do you have a more fleshed out example using AudioWorkletNode that would replace existing use of OfflineAudioContext?

On Fri, Jun 8, 2018 at 1:27 AM TAMURA, Kent <tk...@chromium.org> wrote:

LGTM2

On Fri, Jun 8, 2018 at 3:34 AM Chris Harrelson <chri...@chromium.org> wrote:

LGTM1 to deprecate and try to remove in M70. Please come back with stable channel use counter data on M69 to confirm.

On Thu, Jun 7, 2018 at 11:22 AM Raymond Toy <rt...@chromium.org> wrote:

Quick clarification:

On Thu, Jun 7, 2018 at 11:15 AM Raymond Toy <rt...@chromium.org> wrote:

Interoperability and Compatibility Risk

It’s not clear how much we will break in removing this since there are no use counters for this case. 

By "this case", I meant no counters to show if these nodes are used with an OfflineAudioContext. 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE3TgXFfTai65K0WPUR6%3DNpuZ%3D3h-%3DS8%2BF8WsP%3DYVY0s6CJj%2Bw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-i8J6k72f04LAy38VUjM-X%2Bkjr2z6vYOHv_hA%3DOrhjbg%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqHByM1qyBc0%2B1iAeBQsMTp1_h9C_G1K%2BVwMJbjAYyispg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Harald Alvestrand]

I'm mostly worried about people reacting to the M70 autoplay removal (if it happens) by trying to switch to OfflineAudioContext, and finding that this has been removed too at the same time.

If they get a deprecation warning when they react to the change, or if the API disappeared in the version before the autoplay removal, there should be no big problems.

On Mon, Jun 11, 2018 at 5:49 PM, Raymond Toy <rt...@chromium.org> wrote:

On Mon, Jun 11, 2018 at 4:23 AM Harald Alvestrand <h...@google.com> wrote:

One of the attempts to work around the autoplay issue for the "mike check" of WebRTC applications while we had the autoplay imbroglio used OfflineAudioNode.

We should install an use counter to verify that none of the production services picked up on this workaround and deployed it.

I'm adding usecounters now.  It won't tell you if it's for WebRTC, but we'll at least know how common this is. 

M70 is the same version as the target date for reintroducing the autoplay denial for WebAudio.

I randomly picked M70 since 67 just recently landed.  We can postpone it, but since the autoplay restrictions are coming back in M70, this seemed like a good time. 

On Mon, Jun 11, 2018 at 12:18 PM, 'Philip Jägenstedt' via blink-dev <blin...@chromium.org> wrote:

Hey Raymond,

I'm fairly sure that MediaStreamAudioSourceNode is used for the "mike check" of WebRTC web apps like Hangouts and Meet, although perhaps not together with OfflineAudioContext. Nevertheless, do you have a more fleshed out example using AudioWorkletNode that would replace existing use of OfflineAudioContext?

On Fri, Jun 8, 2018 at 1:27 AM TAMURA, Kent <tk...@chromium.org> wrote:

LGTM2

On Fri, Jun 8, 2018 at 3:34 AM Chris Harrelson <chri...@chromium.org> wrote:

LGTM1 to deprecate and try to remove in M70. Please come back with stable channel use counter data on M69 to confirm.

On Thu, Jun 7, 2018 at 11:22 AM Raymond Toy <rt...@chromium.org> wrote:

Quick clarification:

On Thu, Jun 7, 2018 at 11:15 AM Raymond Toy <rt...@chromium.org> wrote:

Interoperability and Compatibility Risk

It’s not clear how much we will break in removing this since there are no use counters for this case. 

By "this case", I meant no counters to show if these nodes are used with an OfflineAudioContext. 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE3TgXFfTai65K0WPUR6%3DNpuZ%3D3h-%3DS8%2BF8WsP%3DYVY0s6CJj%2Bw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-i8J6k72f04LAy38VUjM-X%2Bkjr2z6vYOHv_hA%3DOrhjbg%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqHByM1qyBc0%2B1iAeBQsMTp1_h9C_G1K%2BVwMJbjAYyispg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Raymond Toy]

I hope to land the deprecation message soon (this week).  I can change the date to 71 if you think it's better. Let me know so I can change the date in the messages before the CL lands.

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE3TgXFfTai65K0WPUR6%3DNpuZ%3D3h-%3DS8%2BF8WsP%3DYVY0s6CJj%2Bw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-i8J6k72f04LAy38VUjM-X%2Bkjr2z6vYOHv_hA%3DOrhjbg%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqHByM1qyBc0%2B1iAeBQsMTp1_h9C_G1K%2BVwMJbjAYyispg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Philip Jägenstedt]

On Mon, Jun 11, 2018 at 6:01 PM Hongchan Choi <hong...@google.com> wrote:

Hi Harald,

>  Nevertheless, do you have a more fleshed out example using AudioWorkletNode that would replace existing use of OfflineAudioContext?

What do you mean by this? How do you replace OAC with the AudioWorkletNode? If that helps Meet or Hangout somehow I would love to look into it.

I wrote the quoted bit. I haven't look into what Meet or Hangouts does in detail, but when starting a new meeting on meet.google.com I find "audiocontext" in the sources in devtools but not "offlineaudiocontext", so they ought to be affected by this change.

https://github.com/mounirlamouri/volume-meter is an example of using OfflineAudioContext that I think will break. If there's no doubt that it can be rewritten then perhaps the exercise isn't worth the effort.

Having the deprecation message soon seems important so that people don't flock to OfflineAudioContext only to be broken again, so LGTM3 to the M70 plan, and checking in on this thread when data is available.

[Hongchan Choi]

Hi Harald,

>  Nevertheless, do you have a more fleshed out example using AudioWorkletNode that would replace existing use of OfflineAudioContext?

What do you mean by this? How do you replace OAC with the AudioWorkletNode? If that helps Meet or Hangout somehow I would love to look into it.

-Hongchan

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE3TgXFfTai65K0WPUR6%3DNpuZ%3D3h-%3DS8%2BF8WsP%3DYVY0s6CJj%2Bw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-i8J6k72f04LAy38VUjM-X%2Bkjr2z6vYOHv_hA%3DOrhjbg%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqHByM1qyBc0%2B1iAeBQsMTp1_h9C_G1K%2BVwMJbjAYyispg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYf%3DU2tZ8Yxh5dRtWgpz1GhAWfxnC9XiVH%2BXQDj%3DpnH7TA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVGtiOUDeg7Q5GjovVh5_8i9YmC6rbM4Kcg1_ZG_%3DOBrLw%40mail.gmail.com.

--

Hongchan Choi

SWE, Google Chrome

[Hongchan Choi]

Using OfflineAudioContext to sneak away from the autoplay policy is an obvious hack. The volume meter example shown above should not be recommended or used.

Furthermore, the microphone permission is a the strongest signal from user that "I want the audio to function correctly", so the browser should honor the intention and lift the autoplay blocking. (This part is still being discussed between the autoplay and webaudio team) If that's the case, the OAC hack would not be necessary for many WebRTC use cases.

[Philip Jägenstedt]

Thanks for the extra context Hongchan, hope that all works out one way or another.

[Raymond Toy]

Harald, would you like to postpone the removal to M71? I want to update the deprecation messages with the correct version.

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE3TgXFfTai65K0WPUR6%3DNpuZ%3D3h-%3DS8%2BF8WsP%3DYVY0s6CJj%2Bw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-i8J6k72f04LAy38VUjM-X%2Bkjr2z6vYOHv_hA%3DOrhjbg%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqHByM1qyBc0%2B1iAeBQsMTp1_h9C_G1K%2BVwMJbjAYyispg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Raymond Toy]

Friendly ping.  Anything else I need to do to get the third lgtm?

[Daniel Bratell]

Nope, there is one hidden in the text of Philip's post. It was a bit invisible so I'd recommend putting them on their own line, but it's there.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE3TgXF8OF%2BOdW_bVcvTMWvm7vjtWcZ%3DcikVU_yPMV8O99yoSw%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Raymond Toy]

Oops. I totally missed that.  Sorry about that!

[Raymond Toy]

Based on https://www.chromestatus.com/metrics/feature/timeline/popularity/2475, https://www.chromestatus.com/metrics/feature/timeline/popularity/2476, and https://www.chromestatus.com/metrics/feature/timeline/popularity/2477,  there appears to be no usage at all of any WebAudio media node with an offline context.

I think it's safe to move ahead with removing these in M70 from an offline context and only allowing these to be connected to an AudioContext.  M70 feature freeze is coming up soon.

[Philip Jägenstedt]

Those 3 URLs all show "Cannot read property 'x' of undefined" for me. That seems like a bug. Do you see a graph, and what are the usages in percent?

[Raymond Toy]

I get the same thing.  I was interpreting that as meaning the call to increment the use counter never got called.  But that might be a bad assumption on my part.  Or maybe I totally screwed up the deprecation counter.

[Philip Jägenstedt]

+Luna Lu, are you able to help debug what those errors mean? Do they
mean that the use counters were never hit at all, or something else?

[Raymond Toy]

Friendly ping.  Any thoughts on why the metrics don't show anything?  The CL that added the metrics is https://chromium-review.googlesource.com/1091656.  I think I got everything right there.

[Luna Lu]

Hi,

I'm on an office off site in Mexico. I didn't bring my work computer. I'll try to look into the problems when I find a work computer.

I'll be on vacation from Oct 2 to Oct 20. Ill be k. China with no Google services. Apologies in advance for my absence in the next few weeks.

Regards,

Luna

[Luna Lu]

Hi,

I do not know top of my head why the feature is not being recorded. But there are a few things we could try:

1. This is the logic for deprecation use counter. We want to verify the caller will have a valid: frame, document, document loader, and a page in order for the use to be counted.

2. We can write a layout test (see example) that triggers the web audio usage and then use internals.isUseCounted(document, ...) to test if usages are being recorded. 

3. The chromestatus.com is sometimes delayed (it uses most dominant version tag and stable) and has some issues with it. So I'd recommend checking the internal usage with UMA dashboard.

Hope that helps.

Meanwhile, if you have further questions, please contact my team internal-feature-control@.

Thanks

[Raymond Toy]

On Tue, Oct 2, 2018 at 9:32 AM Luna Lu <lun...@chromium.org> wrote:

Hi,

I do not know top of my head why the feature is not being recorded. But there are a few things we could try:

1. This is the logic for deprecation use counter. We want to verify the caller will have a valid: frame, document, document loader, and a page in order for the use to be counted.

2. We can write a layout test (see example) that triggers the web audio usage and then use internals.isUseCounted(document, ...) to test if usages are being recorded. 

3. The chromestatus.com is sometimes delayed (it uses most dominant version tag and stable) and has some issues with it. So I'd recommend checking the internal usage with UMA dashboard.

This link shows that there is very, very little usage. I think it's ok to move the methods to the AudioContext.  

Thanks for your help!

[Philip Jägenstedt]

On Wed, Oct 3, 2018 at 12:07 AM Raymond Toy <rt...@chromium.org> wrote:

On Tue, Oct 2, 2018 at 9:32 AM Luna Lu <lun...@chromium.org> wrote:

Hi,

I do not know top of my head why the feature is not being recorded. But there are a few things we could try:

1. This is the logic for deprecation use counter. We want to verify the caller will have a valid: frame, document, document loader, and a page in order for the use to be counted.

2. We can write a layout test (see example) that triggers the web audio usage and then use internals.isUseCounted(document, ...) to test if usages are being recorded. 

3. The chromestatus.com is sometimes delayed (it uses most dominant version tag and stable) and has some issues with it. So I'd recommend checking the internal usage with UMA dashboard.

This link shows that there is very, very little usage. I think it's ok to move the methods to the AudioContext.  

Thanks for your help!

Awesome! This already has 3xLGTM, hope it works out :)

[Raymond Toy]

Fingers crossed. :-)

Thanks for everyone's patience on this.