Web Audio API: User-Selectable Render Quantum Size

[hoch]

こんにちは 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:

• [x] 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

[maxpassion]

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?

[padenot]

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.

[hoch]

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"?

[maxpassion]

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".

[cynthia]

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.