Audio Working Group Charter
The mission of the Audio Working Group, part of the Rich Web Client Activity, is to add advanced sound and music capabilities to the Open Web Platform.
Building upon and expanding the basic functionalities brought by HTML5's <audio> and <video> media elements and MediaStream object, the Audio Working Group will define client-side script APIs which will support the features required by rich interactive applications including the ability to process and synthesize audio streams directly in script, as well as giving access to musical instruments through a bridge with existing system-level MIDI APIs.
This charter makes no changes to the previous charter, other than to establish new timeline estimates for its existing deliverables, and to extend the date for an additional two years.
| End date | 01 December 2016 |
|---|---|
| Confidentiality | Proceedings are public |
| Initial Chairs |
Joe Berkovitz (Noteflight / Hal Leonard Corporation) Matt Paradis (BBC) |
|
Initial Team Contacts (FTE %: 20) |
Doug Schepers |
| Usual Meeting Schedule |
Teleconferences: weekly coordination calls will be held, with additional calls as needed Face-to-face: we will meet during the W3C's annual Technical Plenary week; an additional face-to-face meeting may be scheduled by consent of the participants |
Scope
The audio API will provide methods to read audio samples, write audio data, create sounds, and perform client-side audio processing and synthesis with minimal latency. It will also add programmatic access to the PCM audio stream for low-level manipulation directly in script. This API can be used for interactive applications, games, 3D environments, musical applications, educational applications, and for the purposes of accessibility. It includes the ability to synchronize, visualize, or enhance sound information when used in conjunction with graphics APIs. Sound synthesis can be used to enhance user interfaces, or produce music. The addition of advanced audio capabilities to user agents will present new options to Web developers and designers, and has many accessibility opportunities and challenges that this working group will keep in mind.
The group is integrating the best features from two existing proposal for audio APIs: the Web Audio API, describing the WebKit implementation in Google Chrome and Apple Safari, which provides an additional higher-level graph-based API to perform common functions natively; and the MediaStream Processing API which extends HTML Streams to provide audio mixing and effects processing, which has been published as a Working Group Note.
This working group is guided by the use cases and requirements it has developed in collaboration with other groups and the wider community.
In addition to an audio processing API, this group has received feedback from the audio and music community and industry, who wish to Web-enable their MIDI-capable devices. MIDI is an electronic device interface, developed by the musical instrument industry, that includes communication protocols for two-way connection and control of a wide variety of devices, including digital musical instruments, digital audio workstations, lighting sytems, game controllers, and many other systems. The MIDI specification has wide adoption and interoperable deployment across devices and computer operating systems, and to extend this existing infrastructure, the Audio Working Group will also develop a specification to create a bridge between the browser and existing system-level MIDI APIs, to make musical instruments first-class citizens of the Web.
The scope of this working group includes:
- Developing a client-side script API for processing and synthesizing PCM audio streams, including direct scripted solutions.
- Access to audio devices, such as for microphones or other audio inputs, and multi-channel speakers or other audio outputs.
- APIs and advanced functionality regarding audio cache management and audio capability information.
- Defining a client-side script API for accessing and manipulating MIDI-capable devices available on the users' systems.
This working group will take into account common work-flows for sound creators, including considerations for common audio formats. This group will also liaise with other groups for direct connection to audio inputs, such as microphones.
This working group is expected to collaborate with other groups, such as the HTML Working Group, Device APIs Working Group, Web Real-Time Communications Working Group, or their successors, to define an API for accessing system devices such as microphones, speakers, and audio processors and channels. If work does not proceed elsewhere in a timely fashion, this group may define an API for audio device access.
Real-time communication is an important and related topic, so this group will work closely with the Web Real-Time Communications Working Group to ensure interoperability of the deliverables.
Because the specifications defined by this group carry potential security, privacy, and accessibility concerns, this group will seek guidance from the appropriate groups to ensure technical review. In particular, these APIs are intended to be executed in a browser context, and access to system resources or I/O devices must be defined in a manner consistent with user awareness and control.
Success Criteria
In order to advance beyond Candidate Recommendation, each specification is expected to have at least three independent implementations of each of feature defined in the specification (two desktop browsers, and at least one mobile browser).
Out of Scope
This group will not work on audio representation markup during this charter period; discussions of music notation formats may happen in a Community Group.
The audio API is intended to operate on local and remote sources including synthesis, files, and sound-capture sources. APIs for implementing interactive audio streaming directly between users is not in scope. This group will coordinate with the other groups working in this area, such as the Web Real-Time Communications WG, to discuss the interactive streaming use case and its interaction with the Audio WG APIs.
Specific functionality for speech synthesis is out of the direct scope of this group, though discussions and collaborations may occur with groups chartered to do such work, to ensure broad compatibility.
Audio codec selection and support is out of scope.
Deliverables
The working group will deliver the following W3C Recommendations:
- Web Audio API
-
This specification defines a client-side script interface to allow web applications to read and write raw audio data, to modify audio streams, and to synthesize sound. This specification may be a single API, or a set of modular APIs with increasing levels of capability.
- Web MIDI API
-
Some user agents have connected music devices, such as synthesizers, keyboard controllers and drum machines. The widely adopted MIDI protocol enables electronic musical instruments, controllers and computers to communicate and synchronize with each other. MIDI does not transmit audio signals: instead, it sends event messages about musical notes, controller signals for parameters such as volume, vibrato and panning, cues and clock signals to set the tempo, and system-specific MIDI communications (e.g. to remotely store synthesizer-specific patch data). Additionally, MIDI has become a standard for show control, lighting and special effects control.
This deliverable defines an API supporting the MIDI protocol and MIDI device input and output selection. This API should be defined at such a level as to enable non-music MIDI applications as well as music ones.
Other Deliverables
This group may define audio device access APIs (e.g. microphone and speaker access), in coordination with other groups working on related deliverables.
- Web Audio Processing: Use Cases and Requirements
- This Note introduces a series of scenarios and a list of requirements guiding the work of the W3C Audio Working Group in its development of a Web API for processing and synthesis of audio on the web.
- MediaStream Processing API Note
- This Note describes an alternate set of existing or proposed features for the Web platform that deal with continuous real-time media, which would make HTML Streams the foundation for integrated Web media processing by creating a mixing and effects processing API for HTML Streams. The features and architecture described in this document are being integrated into the Web Audio API.
Other non-normative documents may be created such as:
- Test suites and implementation report for each specification;
- Primer or Best Practice documents to support web developers.
Milestones
| Note: The group will document significant changes from this initial schedule on the group wiki. | |||||
| Specification | FPWD | LC | CR | PR | Rec |
|---|---|---|---|---|---|
| Web Audio API | Dec 2011 | Q2 2015 | Q4 2015 | Q1 2016 | Q1 2016 |
| Web MIDI API | Q3 2012 | Q2 2015 | Q4 2015 | Q1 2016 | Q1 2016 |
Dependencies and Liaisons
W3C Groups
- HTML Working Group
- Ensure that the audio APIs are compatible with the relevant HTML elements
- Protocols and Formats Working Group
- Ensure that use cases, requirements, and specifications include and meet accessibility needs.
- User Agent Accessibility Guidelines Working Group (UAWG)
- Ensure that user agent accessibility requirements for audio features and controls are supported
- Voice Browser Working Group
- Coordinate on issues involving voice control and speech synthesis
- Device APIs Working Group
- Supply use cases, requirements, and review of specifications related to audio, including microphone access and speaker output
- Web Real-Time Communications Working Group
- Supply use cases, requirements, and review of specifications related to audio, including real-time communications
- Web Applications Working Group
- Seek guidance and review on API design, and ensure that this group's use of the Web IDL specification, developed in the WebApps WG, follows best practices.
- Web Applications Security Working Group
- Privacy Interest Group
- Ensure that APIs produced by this group do not introduce security or privacy issues.
External Groups
- MIDI Manufacturers Association
- Coordinate on the relationship between the audio API and the Musical Instrument Digital Interface protocol
- Khronos Group
- Coordinate with on the relationship between the Web Audio API and the OpenSL ES API
- Creative Labs
- Coordinate with on the relationship between the Web Audio API and the OpenAL API specification.
Participation
To be successful, the Audio Working Group is expected to have 10 or more active participants for its duration. The Chairs and specification Editors are expected to contribute one day per week towards the Working Group. There is no minimum requirement for other Participants.
The Audio Working Group will also allocate the necessary resources for building Test Suites for each specification.
The group encourages questions and comments on its public mailing lists, as described in Communication.
The group also welcomes non-Members to contribute technical submissions for consideration, with the agreement from each participant to Royalty-Free licensing of those submissions under the W3C Patent Policy.
Communication
Most Audio Working Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis.
This group primarily conducts its work on the public mailing list public-audio@w3.org (archive). The public is invited to post messages to this list.
Information about the group (deliverables, participants, teleconferences, etc.) is available from the Audio Working Group home page.
The group will use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a participant requests such a discussion.
Information about the group (for example, details about deliverables, issues, actions, status, participants) will be available from the Audio Working Group home page.
Decision Policy
As explained in the W3C Process Document (section 3.3), this group will seek to make decisions when there is consensus and with due process. The expectation is that typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required. However, if a decision is necessary for timely progress, but consensus is not achieved after careful consideration of the range of views presented, the Chairs should put a question out for voting within the group (allowing for remote asynchronous participation -- using, for example, email and/or web-based survey techniques) and record a decision, along with any objections. The matter should then be considered resolved unless and until new information becomes available.
This charter is written in accordance with Section 3.4, Votes of the W3C Process Document and includes no voting procedures beyond what the Process Document requires.
Patent Policy
This Working Group operates under the W3C Patent Policy (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.
For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation.
About this Charter
This charter for the Audio Working Group has been created according to section 6.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.
This charter replaces the previous Audio Working Group charter.
Doug Schepers
Copyright© 2010 W3C ® (MIT , ERCIM , Keio), All Rights Reserved.
$Date: 2016/09/09 16:02:09 $