trackbot, start meeting

<trackbot> Date: 16 April 2012

<scribe> Scribe: Olivier

Decide on the time/day for our teleconferences through Autumn 2012

http://www.doodle.com/ayb6qkrwc94scru7

<Alistair> Olivier: We has switch time, which means Aukland has switched to winter time. The time is 6am in NZ, being quite inconvenient. The best time seems to be 3-4pm Boston time, which is one hour later than now. Based on that I started the poll to see which day would be best for that time. So far the best choice would be Wed. Could people fill this in quickly now so we can work out a date.

Olivier: based on the poll, 3pm Wednesdays (Boston) is a clear winner

<scribe> ACTION: Olivier to change teleconference time (wed 3pm Boston), announce to the group [recorded in http://www.w3.org/2012/04/16-audio-minutes.html#action01]

<trackbot> Created ACTION-44 - Change teleconference time (wed 3pm Boston), announce to the group [on Olivier Thereaux - due 2012-04-23].

valid from next week

Decide on whether we will meet at TPAC and/or for another f2f

https://www.w3.org/2002/09/wbs/46884/f2f2012/results

(Results of poll on TPAC)

<Alistair> Olivier: We need to decide quickly on this. We had a reasonable number of answers on the poll above. A few people said they may not be able to make it, but people seem to agree the telecon should go ahead with meeting at TPAC. We also have the option of canceling and having another F3F elsewhere, but we should book this anyway.

Olivier: I'll reply on behalf of the group

Resolution: we will say yes to meeting at TPAC, assess later whether we need/want to hold another f2f, possibly in East Coast USA

Quick review of issues "Pending Review"

<Alistair> http://www.w3.org/2011/audio/track/issues/3

Al: Destroying audio context

Olivier: this does not seem to be controversial. Ordinary garbage collection rules seemed to be sufficient. Assuming we could close, and let people reopen if need be?

Chris: agreed, I think this is not going to be a problem

Al: is this per tab?

Chris: implementation specific, but I suppose it could be per domain

Doug: it seems that developers don't like undocumented differences between implementations

… and don't like not knowing what they can do

Doug: could we specify a number?

Chris: we could write that the audiocontext can be managed, and that the usual garbage collection holds

Doug: we could document outside of the spec

… document what the limit is

Chris: it's something that is likely to be increased, but it's similar to webGL, an implementation will start complaining if you create too many

… the limit at the moment in webkit is low

… hope that people will use the web audio API in such a way that they won't use too many… there are ways to use it by having one context per page

Doug: mashup scenario

… we want to set some developer expectation

Olivier: we want to avoid documenting limits in the spec

Doug: even hard lower limits

Olivier: doesn't hurt

Al: support Chris' view on this

… if you do a mashup, making things work together would be really difficult unless you share a context anyway

Jer: wanted to make a clarification - iOS doesn't have this yet, but when it does it will be based on the same webkit source

… hence with the same limits

Jussi: satisfied with the solution

RESOLUTION: close ISSUE-3 as satisfying as is, make sure we document limits in the number of contexts - not necessarily in the spec but in some developer doc

<Alistair> http://www.w3.org/2011/audio/track/issues/5

Al: we already have a resolution for this

… I will take care of closing it

<Alistair> http://www.w3.org/2011/audio/track/issues/7

Olivier: just checking if there was progress on ACTION-42 and ACTION-41

Jussi: am having second thoughts about FFTNode

… need more discussion, want to work on a use case for it

Al: Jussi, is there anything specific that had you reconsider?

Jussi: too many edge cases in the use case

… not sure it's a good idea any more

<Alistair> http://www.w3.org/2011/audio/track/issues/raised

review open issues

<chris> https://dvcs.w3.org/hg/audio/

CRogers: some of these will be covered by recent changes to the spec

review of recent editor's draft changes

CRogers: https://dvcs.w3.org/hg/audio/

last 3 changesets: https://dvcs.w3.org/hg/audio/rev/7011f54ec0db https://dvcs.w3.org/hg/audio/rev/38fc7dcef032 and https://dvcs.w3.org/hg/audio/rev/908b6b7b8702

CRogers: start with https://dvcs.w3.org/hg/audio/rev/908b6b7b8702 - https://dvcs.w3.org/hg/audio/raw-rev/908b6b7b8702

… a lot of this is updating the spec with things we talked about but wasn't in the spec yet

… such as the JavaScriptAudioNode

… it's quite a lot of changes

Olivier: we've been struggling with handling of number of channels in the JavaScriptAudioNode

CRogers: yes, the spec wasn't clear and there was a bug in the WebKit implementation too
... I could post to the list with links

Olivier: agree, maybe highlight things that you weren't sure about, and then send mail to the list with details

CRogers: the gain was always nominal like this in the implementation, but the spec was saying it could not be negative
... https://dvcs.w3.org/hg/audio/rev/38fc7dcef032

… addition of Oscillator and WaveTable nodes

… made it into a formal source node

… might be easiest to check in the current ED

… easier to read than the diff

<chris> https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#Oscillator

Al: these changes are not live in /TR

CRogers: only in ED for now, we haven't republished

… implementation-wise, should be in safary and chrome nightlies, except for noteon and noteoff calls

Al: developers I talked to recently were very excited with idea of oscillator nodes

CRogers: yes, and it's reasonably high quality
... there is also a setWaveTable method

Al: question about aliasing

CRogers: not sure we want to add anti-aliasing to the spec
... added commonly used typical wave forms

<Alistair> Chris: I see why alias/anti-alias option on oscillators could be very useful. I think would could add this as a tru or false value.

… the one thing that may be missing is pulse-width modulation

Al: that could be really useful

CRogers: most recent changeset: https://dvcs.w3.org/hg/audio/rev/7011f54ec0db

…added a way to connect an audionode to the audioparam of another node

… something we'd talked about on the list

… especially interesting for FM synthesis

Jussi: cool

CRogers: you can use it for amplitude modulation

… can create quite a few different FM architectures out of this

CRogers: also a lot of cleanup

… will send details to the list

… will also go back to the list over the past few months, see if there is any issue

… hope to be able to publish a 3rd WD soon

<chris> Xylophone demo:

<chris> http://www.soundstep.com/blog/2012/03/22/javascript-motion-detection/?utm_source=rss&utm_medium=rss&utm_campaign=javascript-motion-detection

[discussion about future publications, integration with WebRTC, etc]

ADJOURNED

<jernoble> bye all!

This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Set/set/
Succeeded: s/an audioparam/the audioparam of another node/
Found Scribe: Olivier
Inferring ScribeNick: olivier
Present: Al Doug Olivier Jer Jussi
Agenda: http://lists.w3.org/Archives/Public/public-audio/2012AprJun/0026.html
Found Date: 16 Apr 2012
Guessing minutes URL: http://www.w3.org/2012/04/16-audio-minutes.html
People with action items: olivier

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