<trackbot> Date: 02 October 2014

<scribe> Scribe: olivier

<scribe> ScribeNick: olivier

Previous meeting minutes -> http://lists.w3.org/Archives/Public/public-audio/2014JulSep/0254.html

<kawai> IPcaller

joe: starting the call
... summarises agenda, asks for input on agenda

AudioWorker progress

joe: outstanding questions raised on the list
... lifetime and callback behaviour
... anything else we need to resolve?

cwilso: don't think so

joe: walking through those two questions

<joe> http://lists.w3.org/Archives/Public/public-audio/2014JulSep/0262.html

http://lists.w3.org/Archives/Public/public-audio/2014JulSep/0262.html -> email about lifetime

joe: from a developer point of view, seems like the more urgent of the two issues
... question of when an audioworker node ceases to exist and become eligible for GC
... any views?

cwilso: the way this works is fairly well define, with terminate for workers.
... you can GC if there are no event handler and no reference
... otherwise you probably can't
... experience we have with scriptprocessors is that would be called n times per second
... the issue is frustrating because for every issue requiring aggressive GC, there are cases where we'd stop processing when we should not

joe: reason I included the cases, which come from the spec, is we are trying to implement, at least in theory, native nodes with worker nodes
... not saying we are trying to aggressively automatically GC
... but terminate() does not feel like the answer

cwilso: there are 3 potential cases
... the case where from the main thread you say "I'm done, go away"
... that's what terminate does, there are scenarios where you want that
... second case is where you want to destroy the node from within itself
... decide "i'm done"
... e.g if you were reimplementing buffersourcenode, done playing
... until it's done playing the node itself can't destroy itself
... that's the onaudioprocess, which will be set to no when done

joe: if that's the way to go, we need to add case #5

cwilso: think that's what #4 does

(the 4 cases are from http://lists.w3.org/Archives/Public/public-audio/2014JulSep/0262.html)

joe: think someone in the spec we need to add that onaudioprocess is hook that keeps node alive
... and that you must set the callback to no to kill it
... that'd need to happen to address the case in full

cwilso: agrees

joe: case #4 has additional question, perhaps can be dispensed with
... asking whether there is anything upstream for me that is still active
... is it necessary to implement e.g. convolver or delaynode?

cwilso: don't think it is necessary in API
... the way the node itself manages that is set onaudioprocess to no

joe: but it might need to revive itself

cwilso: possibly
... could use onconnect/disconnect

joe: that would work
... just don't know what priority to set
... the tail-time reference
... don't feel it is a show-stopper

cwilso: feel it needs to be figured out before we can consider the solution complete, don't think it is blocking anything

joe: would block non-native convolvernode

bill(?): kind of ugly

cwilso: not married to that design
... think these nodes will be long lived with graph evolving around them

joe: maybe this issue would benefit from discussion at TPAC - no quorum on the call

resolution: discussion on tail-time reference postponed to TPAC
... document the onaudioprocess = no as way to GC a workernode

cwilso: need to add a lifetime section to the node spec

<joe> http://lists.w3.org/Archives/Public/public-audio/2014JulSep/0263.html

Timing and Sequencing

http://lists.w3.org/Archives/Public/public-audio/2014JulSep/0263.html -> Refining AudioProcessEvent definition of timing and sequencing

joe: a lot of this is not very controversial
... we discussed some of it offline
... found one issue creeping out of this, which is question of consistent buffer sizes

cwilso: spec today has block size of 128
... either stick to that or explicitely make block size completely flexible
... big impact on how latency works in the system
... my take on it ATM would be to keep consistency
... alternative would be lot of work, uncertain gain. We'd gain only cycle limitation with 128 sample delay

joe: not even sure we get rid of that, might make problem even worse

cwilso: note that one stated goal was reduce CPU consumption, can get same effect by batching blocks, already doing that on some systems
... we e.g ask for 4 blocks at a time
... you'd never get a callback for anything different than 128 at a time
... but system may want to batch several at a time
... and go silent for n times as long
... we are guaranteeing monotonically increasing
... but not consistent interval in real time

joe: am hearing you would prefer sticking to 128
... there's more stuck to 128 in the spec than I remember
... moving to second part of http://lists.w3.org/Archives/Public/public-audio/2014JulSep/0263.html
... listed 3 things, one of which I want to forget/reword

cwilso: implementations would balance minimising latency with avoiding buffer overruns
... problem we have is that there are situations we don't want to make that tradeoff
... if optimising for powerconsumption you may want to keep larger buffer around
... thus increasing latency
... topic for f2f as we have a proposal for that?

joe: jer had a proposal
... agreeing to push to TPAC, doesn't affect the API so much

TPAC and Last Call review requests

joe: matt felt it would be good to go through the bugs
... identify whether to fold into v1, last call or not for each issue
... easy to do in a group if we don't stretch it out too long
... another area is testing

don't have a lot of detail, would need to coordinate on the topic

joe: think we'd like final draft after TPAC

olivier: suggest identifying groups to reach out to
... at LC

cwilso: won't have a LCWD at tpac
... given number of issues open
... we are shooting for after TPAC

joe: was mor eabout informal request

olivier: question on how much we want a clear deck of issues before going to LC
... we want to clear all arch issues, but what about smaller issues and feature requests

cwilso: think we would want to only have smaller issues
... easier to decide after our review at TPAC

<cwilso> I'd like to note, BTW, that I will be busy elsewhere Tuesday morning at TPAC

cwilso: also want to note I will be booked on TUE morning for AB presentation at the AC
... so will be in Audio WG Monday and Tuesday PM

AOB?

joe: any other business?

cwilso: one thing to mention - just filed an issue
... consistent request to hook in plugins
... VST support etc
... discussion about that and low level destination hooks
... as part of audioworker design

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

joe: good discussion for TPAC

cwilso: should probably create another issue for IO and [??]

joe: seems reasonable

<kawai> http://www.slideshare.net/yukiotada

kawai: want to talk about it at TPAC - we have built http://www.slideshare.net/yukiotada and have seen issues

cwilso: you recorded a demo of that for last web music hackathon

kawai: the demo was not recorded
... but I can show it at TPAC

olivier: mention seeing dev tools for web audio, sounds interesting, have requested to have a link sent to the list
... have seen it in nightly

cwilso: think it's in regular builds

next meeting in 2 weeks

<cwilso> Jordan Santell's slide deck from the Berlin hackday is at http://jsantell.github.io/web-audio-tools-presentation/#/

<cwilso> (that's on the Firefox web audio dev tools)

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/at/after/
Found Scribe: olivier
Inferring ScribeNick: olivier
Found ScribeNick: olivier
Default Present: +1.408.330.aaaa, joe, +1.650.253.aabb, olivier, BillHofmann, kawai, rtoyg
Present: +1.408.330.aaaa joe +1.650.253.aabb olivier BillHofmann kawai rtoyg
Found Date: 02 Oct 2014
Guessing minutes URL: http://www.w3.org/2014/10/02-audio-minutes.html
People with action items: