Re: Review of Web Audio Processing: Use Cases and Requirements

Hi Michael,

Many thanks for your review. I will be splitting it into several issues to be tracked in our bugzilla. Would you mind me Cc-ing you on each of them? I expect to have a few requests for clarification - in some cases the requirement is clear but we prefer to have clearly stated use cases from which our requirements derive.

Cheers,
Olivier



On 27 Jun 2012, at 20:04, Michael Cooper wrote:

> Doug sent a request to Protocols and Formats Working Group to review Web Audio Processing: Use Cases and Requirements https://dvcs.w3.org/hg/audio/raw-file/tip/reqs/Overview.html. The PFWG is not able to assemble a consensus group review in a quickish turnaround right now, so I am sending my comments individually. I expect other members of PFWG to submit additions later. The version of the document I reviewed was accessed 25 June 2012.
> My review focuses primarily on suggesting requirements for features that would improve accessibility. I haven't proposed use cases but do think we need to develop a use case that explains a user with a screen reader and who depends on audio cues from the operating system, who is also interacting with Web application audio as proposed in the other use cases.
> Need a requirement to allow both per-track and global (with the Web application) control of each audio channel / track / whatever for volume, mute, pause / restart, and autoplay. I think this is implied by the use cases but not spelled out in the requirements.
> Suggest a requirement to allow audio channels to be designated as related to each other (e.g., a voice and instrumental overlay) so a volume change or pause of one of them affects all of the related ones, to allow them to stay in sync, yet allowing "unrelated" tracks (e.g., sound effects) to be treated independently.
> Need a requirement that audio controls not affect system audio settings i.e., should have impact just for audio under control of the Web application. For instance, it would be highly problematic if a "mute" in the Web application muted all system audio. If other requirements mean system audio will be controllable from Web applications (this is not clear to me one way or the other right now), then instead the requirement is that users have an easy way to control whether to allow system audio settings to be impacted by in-application changes (e.g., via a user preference option in user agent).
> 
> The description of audio sprites brings up an issue but not sure of the exact requirement. Sprites that play in response to certain actions could prove extremely distracting to some users or could be more likely to cause momentary problems with comprehension of screen reader output etc. Users should therefore have the ability to prevent audio from playing, not just stop it after it's begun playing. This may be a requirement on Web applications, not on the audio APIs, but it might be the APIs need to make this possible in some way. It would also be helpful to come up with a small ontology of audio roles (for instance, music, speech, sound effects, etc.) so users could easily prevent audio of one type (e.g., sprites) from playing without preventing other types (e.g, music) from playing. Perhaps also needed is a requirement on user agents to offer a preference to users to allow audio to play automatically or only on specific request, recognizing that setting this preference this could interfere greatly with smooth function of some types of applications. 
> Are there issues with needing to provide a way for limits e.g., on total volume when multiple tracks layered, or is this handled by audio equipment? Wouldn't want combinatorial effects to create excessively loud spots. Consider users who have audio volume higher than usual because of hearing impairment, but still we can't allow eardrum-damaging levels to come out.
> 
> Need a requirement to provide ways to avoid triggering audio-sensitive epileptic seizures. The fact that sounds from a variety of sources might be combined, including script-generated sounds and transformations that could have unplanned artifacts, mean the final sound output may be less under the author's control than studio-edited sound. It is important to find ways to reduce unexpected effects triggering audio-sensitive epileptic seizures. To some extent this means warning authors to be careful, but any features we can build into the technology, we should. Unfortunately this is a new field to me and I don't know all the specifics, so it will take research (which of course I volunteer to be involved in, just looking for a placeholder for the issue now). A quick scan online suggests that certain beat frequencies and reverberance effects are known sources of problems. A set of user preferences allowing users to disable or control certain Web application-generated audio transformations might help with the latter issue.
> Need a requirement that audio from the Web application not interfere with system sounds (e.g., alerts), which may contain vital information for the user. While it's probably not desirable to pause Web application audio for system sound events, it's also not desirable to have system sounds drowned out by Web application audio. User preferences may be needed to indicate specifically how to handle the situation, but a way for Web application audio to be aware of system sounds will be needed.
> Operating systems have a feature called "ShowSounds", which triggers a visual indication that an important sound like an alert has occurred. Enabling certain types sounds, like audio sprites, to take advantage of this feature may be important. I expect someone else to provide more details on this requirement but wanted to put a placeholder in this message.
> Michael
> -- 
> Michael Cooper
> Web Accessibility Specialist
> World Wide Web Consortium, Web Accessibility Initiative
> E-mail cooper@w3.org
> Information Page
> 
> 
> -- 
> Michael Cooper
> Web Accessibility Specialist
> World Wide Web Consortium, Web Accessibility Initiative
> E-mail cooper@w3.org
> Information Page
>