W3C

- DRAFT -

Audio Working Group Teleconference

26 Sep 2012

Agenda

See also: IRC log

Attendees

Present
Regrets
Chair
Olivier
Scribe
ot

Contents


<trackbot> Date: 26 September 2012

<gmandyam> Giri Mandyam from QuIC - dialing in from (858) are code

<chris> conference code???

chris: 28346

(audio)

http://lists.w3.org/Archives/Public/public-audio/2012JulSep/0830.html

TPAC update

Olivier: TPAC face to face cancelled

… but we should try and have another one in near future

Olivier: January 2013 might be best
... East coast of US sounds like a decent choice

Joe: would be happy to look into using our facilities (Boston)

… could host up to a dozen people here

Olivier: anything in January we'd want to avoid?

Doug: none that I can think of

… have an SVG f2f in early 2013 (Australia)

<cwilso> If Noteflight doesn't work out, we could probably manage to host in our New York office - I don't know precisely the hosting capacity, but I know it's a huge office.

Doug: Microsoft has a N.E.R.D facility in downtown cambridge too
... supportive of cancelling f2f, but we should try and reach out to DAP/webrtc

… might consider have an overlap?

Doug: note that Boston is not the only place in East Coast

… suggests more towards south

<chrislowis> Anyone else having problems with SIP (zakim@voip.w3.org)?

<jernoble> chrislowis: i'm logged in through sip now; seems fine

chrislowis: not sure - I'm using skype to connect directly to zakim

<chrislowis> I'm getting "cannot connect call at this time". I'll try skype.

Doug: also note west coast possibly easier for some
... may want to consider multiple options

Olivier: agree - I'll start a poll and give a few options

Quick update on recent changes to the specs / early implementations

CWilson: on a the MIDI spec, still hashing out best way to represent sending messages in concise way

… took the spec and wrote a polyfill

… helped discover a few issues and spark changes

… want to expand a bit on the goal / description of the spec

Jussi: recent changes focused on making messages less verbose

… changed MidiMessage to be a dictionary

… so you can simply use JS now

Crogers: we now have experimental version of the media source node for live audio input

… had been in the spec for a while, just implemented

… spurred by ROC's work

… finally had a chance to implement it it webkit, people having fun experimenting with it

… someone did a guitar tuner, done very well

… really nice to let people experiment with live audio sources

… also plan on implementing media source for RTC peers

… something that had been in our use cases

… again, was in the spec for a while

… Otherwise, just got around to names changes, including a section about deprecated old names

Olivier: make sure to update issues

chartering

Doug: we put up the group for rechartering. No objection. only some comments

… we got approval, will be sending the announcement today

… we can start thinking about publishing FPWD of MIDI spec

Graph introspection / determine connection state of an AudioNode https://www.w3.org/Bugs/Public/show_bug.cgi?id=18488

joe: the issue is that if you are trying to write code that modifies a piece of the audio node graph based on current configuration

… there doesn't appear to be a way to find a node and know what is connected to it

crogers: it's quite easy to create a wrapper object to keep track

… but not built in

… base API is already quite complex

… also, graph is not static

… can be changed at quite high rate

<cwilso> THE ICE CREAM TRUCK MAN IS HERE!!!!!!!!

Jussi: worried about 3rd party code

[missed the last bit]

Crogers: hosting application can define representation

Jussi: one example would be cwilson's vocoder app

… creates quite a complex graph

crogers: desktop world have standard plugins which have to expose strictly defined interface

… a standard of some kind is going to have to be developed

[discussion about levels of abstraction and managing connections]

joe: it seems like a basic function, is the concern about implementation or instability of state?

crogers: partially it's a worry about complexity added to the API

… would feel bad adding on more complexity for implementors

… probably best for v2

joe: sounds good

RESOLUTION: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18488 to be tackled later. Probably not for v1

DAP

<shepazu> http://lists.w3.org/Archives/Public/public-device-apis/2012Sep/0044.html

<shepazu> http://lists.w3.org/Archives/Public/public-device-apis/2012Sep/0051.html

Doug: sent some comments to the DAP WG on the Media Capture

… 2 main comments were rejected

<shepazu> http://lists.w3.org/Archives/Public/public-device-apis/2012Sep/0048.html

scribe: 2 issues

… one was about the type of media requested

… one of the value is camcorder (instead of video camera)

<shepazu> http://www.w3.org/TR/2012/WD-html-media-capture-20120712/

… camera is still camera, camcorder is video camera

… suggested change of wording

… response was that the term was already used

Olivier: agree, the terms are weird. Would probably go for something more abstract (image/video)?

Crogers: what is this API for?

Doug: this is the capture attribute on the input element

… not clear how this relates to getUserMedia

jussi: more related to forms

Olivier: could be a good comment to send, ask to explain relationship / difference with getUserMedia

<jernoble> regrets; i have to leave a bit early. bye!

Giri: seems to come from a request for declarative

… possibly will have implementation issues, esp. versus getUserMedia

Doug: suggest people should chime in

… help the DAP group make the right decision

Doug: second issue - video camera access assumes access to microphone

… you can say microphone separately

crogers: that's the case with getUserMedia, they are separate

Doug: should ask access to the two separately
... please chime in on the thread
... will make sure coordination happens, but wanted either reality check or support on the issue

RESOLUTION: the group would like to request that The HTML Media Capture specification defines its relationship with GetUserMedia
... the group would like to request that The HTML Media Capture specification follows same naming/approach to access to video/microphone as getUserMedia

Olivier: anything else

Next Teleconference: 17th October, same time/place

Olivier: KUTGW, talk to you in 3 weeks

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2012/09/26 17:04:07 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

No ScribeNick specified.  Guessing ScribeNick: ot
Inferring Scribes: ot

WARNING: No "Present: ... " found!
Possibly Present: CWilson Doug Doug_Schepers Giri IPcaller Jussi Olivier P53 P57 P76 P85 P9 aaaa audio chris chrislo chrislowis colinbdclark crogers cwilso foolip gcardoso gmandyam inserted jernoble joe joined ot paul_irish rtoyg shepazu tmichel tmichel_ tmichel__ trackbot
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Agenda: http://lists.w3.org/Archives/Public/public-audio/2012JulSep/0830.html
Found Date: 26 Sep 2012
Guessing minutes URL: http://www.w3.org/2012/09/26-audio-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]