F2F 2021 Minutes for Tue May 11

May 11Attendees

Jack Schaedler, Philippe Milot, Jeff Switzer, Michel Buffa, Hongchan Choi,
Raymond Toy, Paul Adenot, Matthew Paradis, Ruth John, Chris Lilley
Minutes

   -

   16:00-16:10 UTC (9:00-9:10 am PDT): Set up calls
   -

   16:10-16:30 UTC (9:15-9:30 am PDT): V2 spec writing logistics (How to
   create the V2 spec)
   -

      Paul: What happens with the V2 repo?
      -

      Raymond: Good question
      -

      Paul: Want to keep the same URLs
      -

      Raymond: I think draft gets the new stuff (highlighted).  Then after
      appropriate review, it can be merged to the Recommendation.
      -

      ChrisL: Yes, that’s the idea.
      -

      Raymond: What to do with v2 issues?
      -

      Paul: Leave it for now until rec is finished, then try to move issue
      to v1 and see if everything is ok.  Then move everything to v1.
      -

      Raymond: Seems reasonable to me.
      -

      Paul: That simplifies lots of things.
      -

   16:30-17:30 UTC (9:30-10:30 am PDT): Render capacity
   -

      Hongchan: Requested privacy review, but no info yet.
      -

      Hongchan; See
      https://github.com/WebAudio/web-audio-api-v2/issues/40#issuecomment-838777404
      -

      Philippe: I’d probably use the polling method at the time when we do
      profiling
      -

      Jeff: Polling is better for CPU chart kind of things, Event for
      notifications.
      -

      Hongchan: Could build event-based on top of polling
      -

      Paul: Problem with polling is missing peak usage.
      -

      Raymond: In the original, we were going to provide the peak.
      -

      Michel: Could have both.
      -

      Hongchan: We could have both.
      -

      Paul: Some might just want to have an event to see when overload
      happens.  But games might want to poll.
      -

      Michel: What does capacity mean?
      -

      Hongchan: It’s the CPU usage, the fraction of time spent on the graph
      compared to the time allowed
      -

      Jack: What is `measuringInterval` in the polling approach? Is the
      measuring interval how often you calculate capacity? If it's 1, does that
      mean, "measure each render quantum"?
      -

      Hongchan: measuringInterval is in sec.
      -

      Hongchan: Can we do peaks like a VUmeter
      -

      Paul: Yes.
      -

      Jack: Knowing the peak over the last sec would be nice.  And also the
      number of underruns over some time period.
      -

      Jack: Having the max value over the last n renders is probably good
      enough.
      -

      Raymond: I think we need both peak and average.
      -

      Hongchan: So peak, average, and number of underruns.
      -

      Jack: With events, might end up doing your own polling anyway.
      -

      Jeff: I prefer polling.
      -

      Raymond: Anyone look at computePressure?
      -

      Hongchan: Sampling interval is fixed.
      -

      Paul: Compute pressure provides useful info, but not solving the same
      problem.
      -

      Hongchan:  So, providing just the 3 values seems like enough.
      -

      Hongchan: will look into computePressure a bit.
      -

      [Hongchan summarizes]
      -

      Jeff: What about offline context?
      -

      Hongchan: Only available for real-time.
      -

      Paul: Remember performance.now will be exposed in worklets.  Will
      allow different methods.
      -

   17:30-18:00 UTC (10:30-11:00 am PDT): User-selectable size
   -

      Michel: I’m a bit annoyed by the hint aspect.  I want to have exactly
      what I want.
      -

      Paul: What happens if you request something not possible?
      -

      Phillipe: Should be able to see what was done.
      -

      [Paul; explains how it works; setting a hint does something and the
      actual value used is exposed as an attribute in the context]
      -

      MIchel: What about latencyHint and renderSizeHint?
      -

      Phillippe: I think you only do one, not both.
      -

      Paul: For some cases, you want HW for render size, but high
      latencyHint.
      -

      Raymond: That is one problem with the API.  What if you want 2k
      render size, but have interactive latencyHint?  Don’t know what to do.
      -

      Philippe: Confusing how this works if you’re not familiar with the
      thistory.  So add “HW” in context constructor to make it explicit.
      -

      Hongchan; I think Brave has a fixed sample rate, for privacy.
      -

      Paul: Firefox does the same in anti-fingerprinting mode.
      -

      [Raymond: see
      https://github.com/rtoy/web-audio-api/blob/13-user-render-size-explainer/explainer/user-selectable-render-size.md
      ]
      -

      Jeff: What happens if the sample rate changes (due to HW change)
      -

      Paul: context sample rate doesn’t change.  Time might pause.
      -

      Phillippe: We’d probably always use HW render size, with interactive
      latency.
      -

      Paul: from game devs probably don’t want latency below video refresh.
      -

      Hongchan: So choose HW and interactive to limit buffering?
      -

      Phillippe: Wyze does it’s own buffering, so want to limit buffering
      so we can control it ourselves.
      -

      Paul: What happens if 3021 is requested?
      -

      Raymond: Don’t know.  But we should be consistent across browsers
      -

      Paul: Round up to supported value and clamp to power of two?
      -

      Raymond: Yes, except Chrome can do non powers-of-two (if implemented).
      -

      ChrisL: rounding up seems better, round up to next supported interval?
      -

      [Raymond: To clarify how to handle this case and figure out how
      latencyHint and rendersize work.]
      -

   Other business
   -

      Raymond: What’s your availability tomorrow since you said you might
      not be around?
      -

      Paul: Can’t make it on Wed.  Let’s move things from May 19 to
      tomorrow?
      -

      Raymond: That’s fine.
      -

      Hongchan: That works better for me too.