Re: [w3ctag/design-reviews] Web Audio API: RenderCapacity API (Issue #843)

Hello there! We looked at this today during a breakout. 

Other TAG members will comment with other components of the review, but we had some questions wrt API design. We need to better understand how this API fits in to the general use cases where it will be used. Currently, the explainer includes a snippet of code showing this in isolation, where it is modifying parameters in the abstract. What is the scope of starting and stopping this kind of monitoring for the use cases listed? Are authors expected to listen continuously or sample short periods of time (because monitoring is expensive)?
  
  If they are expected to listen continuously, then what is the purpose of the `start()` and `stop()` methods? If their only purpose is to set the update interval, that could be a property directly on `AudioContext` (in which case the event would be on `AudioContext` as well and would be named in a more specific way, e.g. `rendercapacitychange`).
  
  We were also unsure what the update interval *does* exactly. Does it essentially throttle the event so you can never get more than one event per that period? Does it set the period over which the load is aggregated? Both? Can you get multiple `update` events without the load actually changing?
  
  Lastly, as a very minor point, `change` is a far more widespread naming convention for events compared to `update`, see https://cdpn.io/pen/debug/dyvGYoV `update` makes more sense if the event fires every `updateInterval` regardless of whether there was a change, but it produces better DX to only fire the event when the value has actually changed so that every invocation is meaningful.

We were also wondering how this relates to https://github.com/w3ctag/design-reviews/issues/939 ?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/843#issuecomment-2018990173
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/843/2018990173@github.com>

Received on Monday, 25 March 2024 21:57:49 UTC