Audio Working Group Teleconference -- 19 Dec 2011

<olivier> trackbot, start meeting

<trackbot> Date: 19 December 2011

<scribe> scribe: kinetik

<chrislowis> Scribe: kinetik

<quinnirill> what was the voip address again?

<olivier> zakim@voip.w3.org

<quinnirill> oyea, thanks

<quinnirill> Alistair: can you hear me? :D

<Alistair> No

<Alistair> :-/

<olivier> nope

<quinnirill> meh -.-

<Alistair> Shout a little louder.

<quinnirill> reinstalled voip a few minutes ago

<Alistair> Ah. Can you hear us OK?

<Alistair> :)

<scribe> agenda: http://lists.w3.org/Archives/Public/public-audio/2011OctDec/0150.html

<olivier> hmm no

We've published our FPWDs! Now what?

olivier: process-wise there are two steps. can either make some modifications, republish, and then go to last call.

<chrislowis> olivier: yes.

olivier: want to get to a point where we're happy with the state of the draft(s)
... then we can go to last call (which is really a first call). idea is to solicit feedback from outside the group.
... likely will not get a lot of feedback until last call, usually have multiple last calls
... try to solicit feedback early, interact with webrtc, html5, other groups to get early review.

shepazu: supports this approach 100%

olivier: continue work on requirements & use cases to produce a record of what decisions were taken and why
... starting from two mature proposals, but still need rationale for what is being produced

shepazu: should not imagine this is the final version of the API, this is the first version, will have requests for more features down the track
... track the feature requests, architecture should provide ability to be extended for later versions

<Alistair> http://www.w3.org/2011/audio/wiki/Requirements

Alistair: started working on requirements (link above)
... need to discuss testing

shepazu: w3c putting together test infrastructure

Alistair: testing low latency playback of sound is very difficult to automate

shepazu: not all tests must be automated, but automate what we can
... think about how tests fit into implementers test frameworks to avoid duplication of effort
... allows implementers to incorporate these tests, and will encourage implementers to contribute tests back
... different categories of specification: must, should, may, must not, and should not
... normative vs informative; example code, implementation notes, background explanation are all informative
... normative (must, should, may, etc.) can be softened, only essential items are covered by royalty free
... if spec says you must do something a certain way, and is covered by patent, then royalty free license for patent is given
... if spec says should do something a certain way, that does not provide royalty free commitment
... maximum patent safeness = use must everywhere possible

<chrislowis> +q

Alistair: merging basic examples (http://www.w3.org/2011/audio/wiki/Basic-Examples) and use cases (http://www.w3.org/2011/audio/wiki/Use-Cases)

<scribe> ACTION: shepazu to set up new requirements page for history purposes [recorded in http://www.w3.org/2011/12/19-audio-minutes.html#action01]

<trackbot> Created ACTION-8 - Set up new requirements page for history purposes [on Doug Schepers - due 2011-12-26].

Alistair: divide up work and get everyone working on something over a week

chrislowis: what level do requirements need to be written at? e.g. for two different approaches to reverb effect (in each spec), so how do we write requirement to cover both specs?
... both APIs can do same things, but go about it in different ways.

Alistair: (example) would say "must be able to do reverb", "should be able to do impulse reverb"

shepazu: will be debating requirements, so write requirement as must (if it's required) or should (if it'd be nice). 'should' will probably not make v1.
... 'must have reverb', 'should have impulse reverb', 'may do it this way or that'.

olivier: wiki has history, edits are signed, so use wiki to write requirements, and invite discussion on mailing list.
... link requirements to use cases
... requirements won't solve approach of which API is preferable, but will make it possible to see which requirements conflict and then can decide which requirement to kill or how to compromise
... crogers wanted to backport requirements from his spec

chrislowis: interested in working on this, will talk to crogers about where he can help

Alistair: asking if there is one requirements document that will unify approach

shepazu: and in the darkness bind them
... this document is for what our API should do, not inclusive of webrtc/etc.

f2f

Use cases and Requirements (discussion above)

f2f (if there is any news)

<Alistair> lol

olivier: question of whether to have the f2f at NAMM
... Google invited f2f to be hosted at Venice Beach Google office, or if preference is to host in Anaheim (where NAMM is), Google may assist with financing conference room
... recommend going with Venice Beach office as it may be easier to organize
... not too far from Anaheim

shepazu: agrees
... easier to organize, plus wifi will be available, avoids being distracted from NAMM

olivier: need to decide on a date, near date of NAMM but not during
... maybe best just after; 23-24th January

shepazu: two days for f2f

Alistair: so much to do, could fill a week

olivier: one day too little, a week difficult for people to attend
... will go back to Google with planned dates

Next call (when?)

<Alistair> http://www.doodle.com/grdv8dmy7gf2dqpc

<olivier> ACTION: Olivier to get back to Crogers and Google, make sure they can host us in Venice Beach Google office on 23-24 Jan 2012 [recorded in http://www.w3.org/2011/12/19-audio-minutes.html#action02]

<trackbot> Created ACTION-9 - Get back to Crogers and Google, make sure they can host us in Venice Beach Google office on 23-24 Jan 2012 [on Olivier Thereaux - due 2011-12-26].

<olivier> +1

Alistair: roc and crogers available Jan 9th, so let's have next call then
... will continue working on requirements, anyone who wants to help please email, also available for phone calls

olivier: send an email to the list after making changes to get attention and solicit feedback

shepazu: w3c discussing idea of having a test manager/test editor, who is responsible for testing
... may be the spec editor, but idea is to divide work

Alistair: sounds good, let's discuss next call and find a volunteer

shepazu: tradionally driven by implementers wanting particular features in spec, so providing tests for that feature

- DRAFT -

Audio Working Group Teleconference

19 Dec 2011

Attendees

Contents

We've published our FPWDs! Now what?

f2f

Use cases and Requirements (discussion above)

f2f (if there is any news)

Next call (when?)

Summary of Action Items

Scribe.perl diagnostic output