#895: Web Audio API: User-Selectable Render Quantum Size

Visit on Github.

Opened Sep 11, 2023

こんにちは TAG-さん!

I'm requesting a TAG review of User-Selectable Render Quantum Size.

Historically, WebAudio has always rendered the graph in chunks of 128 frames, called a render quantum in the specification. This was a trade-off between function-call overhead and latency. A smaller number would reduce latency, but the function call overhead would increase. With a larger value, the overhead is reduced, but the latency increases because any change takes more audio frames to reach the output.

  • Explainer¹ (minimally containing user needs and example code): User-Selectable Render Quantum
  • User research: N/A
  • Security and Privacy self-review²: See the Security/Privacy section in the explainer.
  • GitHub repo (if you prefer feedback filed there): https://github.com/WebAudio/web-audio-api
  • Primary contacts (and their relationship to the specification):
    • Hongchan Choi ([hoch]), W3C Audio Working Group Co-chair
    • Paul Adenot ([@padenot]), Web Audio API specification editor
  • Organization(s)/project(s) driving the specification: W3C Audio Working Group
  • External status/issue trackers for this feature: N/A

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): N/A
  • The group where standardization of this work is intended to be done ("unknown" if not known): W3 Audio WG
  • Existing major pieces of multi-stakeholder review or discussion of this design: N/A
  • Major unresolved issues with or opposition to this design: N/A
  • This work is being funded by: N/A

We'd prefer the TAG provide feedback as (please delete all but the desired option): 💬 leave review feedback as a comment in this issue and @hoch @padenot

Discussions

Discussed Oct 1, 2023 (See Github)

bumped

Discussed Oct 1, 2023 (See Github)

Max: not sure whether this api.. it's used by one particular web application, to set the rendering frequency of the device. Wondering whether this will apply to other applications. Is it per application? Should not have any influence to other applications running on the devices, one particular application wants to use it. [will leave comment]

Comment by @maxpassion Oct 24, 2023 (See Github)

Hi @hoch, we had a discussion in our breakout C meeting today. We have one question: Will this API also affect other web applications that running on the same device?

Comment by @padenot Oct 24, 2023 (See Github)

No more than implementations have decided to make running an AudioContext affect other web applications (or any application) running on the same device today.

Creating and starting an AudioContext, in the overwhelming majority of cases (the exception being if the AudioContextLatencyCategory is "playback"), will start a low-latency real-time audio stream on the device. This in turns can, depending on the OS and various other factors, lower the global latency and/or buffer size of all apps on the machine, or at least the programs that are using the same audio device.

This is the case for any program that make use of low-latency audio. Allowing authors to pick a buffer size, or asking the OS for the best buffer size to use, isn't going to negatively change the impact of a web application on the rest of the system, because the default always has been something quite impactful already.

Comment by @hoch Oct 24, 2023 (See Github)

Re: @maxpassion

Will this API also affect other web applications that running on the same device?

@padenot wrote a detailed explanation above! Additionally to answer your question more directly, "No".

I also have a question. What's "break C meeting"?

Comment by @maxpassion Oct 25, 2023 (See Github)

Re: @maxpassion

Will this API also affect other web applications that running on the same device?

@padenot wrote a detailed explanation above! Additionally to answer your question more directly, "No".

I also have a question. What's "break C meeting"?

Sorry for the typo, it should be "breakout C meeting".

Discussed Jan 1, 2024 (See Github)

Yves: it looks like it makes sense... I looked at it before and felt it looked OK.

Sangwhan: there is a user need. This is well thought-through.

Yves: It's mostly hints so there is an implicit graceful degredation....

Sangwhan: agreed... the application should have a right to request... I'm an LGTM.

Yves: Same.

Comment by @cynthia Jan 25, 2024 (See Github)

Discussed (between @torgo, @ylafon and myself) during London F2F. The problem statement is clear, we like the fact that there is a path for graceful degradation, and it is a well thought-through solution to the given problem. LGTM from us.