See also: IRC log
<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
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
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
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
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:[End of scribe.perl diagnostic output]