W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

[web-audio-api] (HardwareScalability): Hardware Scalability section is vague and incomplete (#88)

From: Olivier Thereaux <notifications@github.com>
Date: Wed, 11 Sep 2013 07:28:15 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/88@github.com>
> Originally reported on W3C Bugzilla [ISSUE-17372](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17372) Tue, 05 Jun 2012 11:56:34 GMT
> Reported by Philip J├Ągenstedt
> Assigned to 

Audio-ISSUE-87 (HardwareScalability): Hardware Scalability section is vague and incomplete [Web Audio API]


Raised by: Philip J├Ągenstedt
On product: Web Audio API


This section contains normative (RFC2119) language but looks like it's design requirements that were input to creating the spec and or implementation. A number of different approaches are mentioned, but none are required. There are a few particularly strange statements:

"The system should gracefully degrade to allow audio processing under resource constrained conditions without dropping audio frames."

"First of all, it should be clear that regardless of the platform, the audio processing load should never be enough to completely lock up the machine."

"The system should be able to run on a range of hardware, from mobile phones and tablet devices to laptop and desktop computers."

What is the system? Are these really intended to be normative requirements?

"In order to avoid audio breakup, CPU usage must remain below 100%."

This certainly doesn't look like a normative requirement, it's just "must" used in a non-RFC2119 way.

These may-level requirements are worrying:

"It may also be exposed through a cpuUsage attribute of AudioNode for use by JavaScript."

"An AudioNode can have a priority attribute to help determine the relative importance of the voices."

Either AudioNode expose the attributes, or it does not.

There are more issues, but we recommend to drop the section entirely. If any of it should remain, we will have to go over it in more detail.

Reply to this email directly or view it on GitHub:
Received on Wednesday, 11 September 2013 14:28:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:24 UTC