W3C

- DRAFT -

Audio Working Group Teleconference

08 Jan 2015

See also: IRC log

Attendees

Present
jdsmith, +1.650.253.aaaa, mdjp, hongchan, cwilso, +1.617.455.aabb, joe, ChrisL, padenot, Doug_Schepers
Regrets
Chair
mdjp
Scribe
cwilso

Contents


<trackbot> Date: 08 January 2015

<rtoyg_m> Zakim: aaaa is me

<mdjp> Zakim P3 is me

<rtoyg_m> Zakim aaaa is me

<scribe> scribenick: cwilso

Proposal for separate multiple-I/O AudioWorker API and single-I/O AudioWorker API (action from previous meeting)

mdjp: cwilso, has this been done?

cwilso: the former (multi-io) has been proposed, the latter (factory model) has not.

<joe> http://cwilso.github.io/web-audio-api/

http://cwilso.github.io/web-audio-api/#widl-AudioContext-createAudioWorker-AudioWorkerNode-DOMString-scriptURL-Array-inputs-Array-outputs

cwilso: talks through the proposal's createAudioWorker

http://cwilso.github.io/web-audio-api/#h3_the-audioworker

http://cwilso.github.io/web-audio-api/#idl-def-AudioProcessEvent

bitcrusher example:

var inputBuffer = e.inputs[0][channel];

var outputBuffer = e.outputs[0][channel];

cwilso: it's unfortunate that the 99% case gets harder due to the 1% scenario

joe: points out that input channels shouldn't be dynamically changeable

mdjp: we should post to the list asking for more review of this and put it on the next agenda

joe: I think the current proposal seems fine (and we probably shouldn't multiply the number of ways to do similar things)

Audio Worker "bypass" Attribute #456 (In the "needs WG Decision" queue)

mdjp: should we put factory model on for next time?

cwilso: sure, although I may not have it done. :)

<mdjp> https://github.com/WebAudio/web-audio-api/issues/456

cwilso: I think we should punt for v1

paul: +1

joe: +1

<mdjp> zakim, take up agendum 3

<padenot> mdjp: I can't really get anything you're saying from here

Inter-app audio (Consistent request from ISVs, a la VSTs, Audio Units, Rack Effects) #358 (In the "needs WG Decision" queue)

<joe> mdjp: can't understand you. try muting while you speak

<joe> never mind

<joe> stupid idea

<mdjp> https://github.com/WebAudio/web-audio-api/issues/358

cwilso: I think we should keep this moving along.

jerry: is this still a v1 topic?

cwilso: I think "v1" is just a name. I think we need to examine the underlying architecture of audio, and how bits move around in the system. I think interapp audio is in the same bucket as access to different inputs/outputs and direct stream access

<ChrisL> I agree, interap audio is important and hard and could be deferred from v1

joe: to me interapp audio comes later than defining the processing system. IAA shouldn't gate the viability of this api.
... we could just get rid of numeric milestones, although I'm not necessarily recommending that

mdjp: I agree with that; this doesn't really fit into the v1/vnext taxonomy; we need some action to resolve it either way, though.

shepazu: even if this isn't in the first Rec spec, we still want to make sure we have the architectural pieces to accomodate it later

https://github.com/WebAudio/web-audio-api/issues/445

cwilso: I think this is kind of blocked behind the input and output stream magic

joe: do you mean we need to abstract sources/destinations outside of the WA api?

cwilso: yes: we need to crack open how source/destinations work.

<ChrisL> our use cases are not their use cases, basically

joe: we seem to get hung up in the RTC realm on the enumerations. Can we make progress on the abstractions anyway?

shepazu: the goal of the platform is to be well-integrated, which is why we encourage cross-WG coordination. We *can* put forward ideas in the RTC space.
... we should come up with what we want to see from the RTC group and talk through it with them.

cwilso: we need bare metal APIs for audio API. I think it's this group's responsibility to make sure those are happening. Some bits are being defined in RTC - which is fine, and they're doing a reasonable job - but driving that "audio streaming" api is not their milieu, today.

chrisl: pinning down requirements here is likely critical.

cwilso: the audio wg likely has two levels we need to work on: the current processing API, and bare metal access to audio i/o and device enumeration.

shepazu: chairs should schedule time for us to talk about use cases / scenarios.

cwilso: we have use cases - we should probably look at them again.

joe: yeah, I wrote a lot of them - I should probably take a look again.

shepazu: I'll get on getting github issues reflected to the mailing list.

<mdjp> trackbot, end meeting

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/01/08 18:01:57 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: cwilso
Inferring Scribes: cwilso
Default Present: jdsmith, +1.650.253.aaaa, mdjp, hongchan, cwilso, +1.617.455.aabb, joe, ChrisL, padenot, Doug_Schepers
Present: jdsmith +1.650.253.aaaa mdjp hongchan cwilso +1.617.455.aabb joe ChrisL padenot Doug_Schepers
Found Date: 08 Jan 2015
Guessing minutes URL: http://www.w3.org/2015/01/08-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]