13:29:11 <RRSAgent> RRSAgent has joined #audio
13:29:11 <RRSAgent> logging to http://www.w3.org/2015/06/01-audio-irc
13:29:13 <trackbot> RRSAgent, make logs world
13:29:15 <trackbot> Zakim, this will be 28346
13:29:15 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
13:29:16 <trackbot> Meeting: Audio Working Group Teleconference
13:29:16 <trackbot> Date: 01 June 2015
13:29:24 <ChrisL> zakim, this meeting spans minight
13:29:24 <Zakim> I don't understand 'this meeting spans minight', ChrisL
13:29:39 <cwilso> zakim, this meeting spans midnight
13:29:39 <Zakim> I don't understand 'this meeting spans midnight', cwilso
13:29:47 <kawai> kawai has joined #audio
13:29:49 <joe> joe has joined #audio
13:29:55 <ChrisL> rrsagent, this meeting spans midnight
13:31:16 <ChrisL> zakim, pick a victim
13:31:16 <Zakim> sorry, ChrisL, I don't know what conference this is
13:31:21 <BillHofmann> BillHofmann has joined #audio
13:31:27 <ChrisL> zakim, this is webaudio
13:31:27 <Zakim> sorry, ChrisL, I do not see a conference named 'webaudio' in progress or scheduled at this time
13:31:36 <ChrisL> oh zakim get a grip
13:31:53 <Todd> Todd has joined #audio
13:32:26 <ChrisL> http://www.w3.org/2015/07/zakim.html
13:33:03 <BillHofmann> scribenick BillHofmann
13:33:25 <BillHofmann> zakim, this is webaudio
13:33:25 <Zakim> sorry, BillHofmann, I do not see a conference named 'webaudio' in progress or scheduled at this time
13:35:54 <BillHofmann> Joe: we can start working back from the goal
13:36:03 <BillHofmann> Joe: in pretty good shape WRT issues in the spec
13:36:24 <BillHofmann> Matt: we should "fan the work out" to be more efficient
13:37:06 <BillHofmann> Joe: wide review will be the easiest thing to accomplish - lots of folks interested in the spec
13:37:36 <BillHofmann> Agenda: two halves - more discussion of issues (Monday); schedule/work plan (Tuesday)
13:37:49 <BillHofmann> Joe: no hard and fast rule about "what will be done" by TPAC
13:39:35 <BillHofmann> ChrisL: used to have Last Call; now you just have to show what you did before CR; used to be that if you did CR and had major changes, you had to go back to LC
13:40:08 <BillHofmann> ChrisL: aim is a document that includes all feedback, response, and feedback makers' response to this
13:40:30 <BillHofmann> Doug: two main issues - finishing the spec; completing a test suite and getting implementation reports
13:41:28 <BillHofmann> zakim, this is audio
13:41:28 <Zakim> sorry, BillHofmann, I do not see a conference named 'audio' in progress or scheduled at this time
13:43:38 <BillHofmann> Doug: need (for tests) to have a Test Tsar - first identify key features to test as a requirement for CR
13:43:44 <BillHofmann> Doug: need to do implementation reports
13:45:11 <BillHofmann> ChrisL: test can also come when there is a difference in implementations
13:45:28 <BillHofmann> Doug: can issue errata on a spec if we find a bug
13:45:49 <BillHofmann> Matt: how long do you leave things open; etc
13:46:27 <BillHofmann> Doug: realistically, need to have a set of key tests, and at least two passing implementations of each of these
13:47:31 <BillHofmann> Doug: then, 3 months for technical and organizational review (includes steps in there)
13:51:35 <BillHofmann> Doug: SVG has had a group "stay at home F2F" - all on IRC, can jump on the phone - if we had 2-3 of those < TPAC, we could actually get the spec done before TPAC
13:52:01 <BillHofmann> Doug: post-TPAC, concentrate on getting tests in - could be done by a few months after TPAC
13:55:05 <BillHofmann> Roll Call:
13:55:42 <BillHofmann> Doug Scheppers - W3C Staff Rep
13:55:58 <BillHofmann> Bill Hofmann - Dolby
13:56:08 <BillHofmann> Todd Gehring - Dolby
13:56:22 <BillHofmann> (focused on browser technology)
13:56:47 <BillHofmann> Joe Berkowitz - President of Noteflight
14:00:00 <BillHofmann> Chris Wilson - Google; spec editor for Web MIDI, ex-WebAudio spec editor
14:02:19 <BillHofmann> Hongchan Choi - Google - works on Blink
14:03:30 <BillHofmann> Chris Lilly - W3C Staff Rep
14:04:12 <ChrisL> s/Lilly/Lilley/
14:04:15 <BillHofmann> Raymond Toy - Google - works on WebAudio
14:05:10 <BillHofmann> Kawai - Yamaha (AMEI)
14:05:27 <BillHofmann> Matt Paradis - BBC (co-chair)
14:05:39 <BillHofmann> s/Noteflight/Noteflight - co-chair/
14:06:02 <BillHofmann> Paul Adenot - Mozilla
14:06:11 <colinbdclark> colinbdclark has joined #audio
14:07:07 <BillHofmann> ---------------
14:07:41 <BillHofmann> Next item - walking through things needing reviews;
14:08:18 <ChrisL> s/Next item/Topic:/
14:08:46 <ChrisL> https://github.com/WebAudio/web-audio-api/labels
14:08:50 <BillHofmann> thanks
14:10:08 <joe> https://github.com/WebAudio/web-audio-api/issues?q=is%3Aopen+is%3Aissue+milestone%3AUncommitted+sort%3Acreated-asc
14:11:15 <BillHofmann> Issue 391 - Specify nominal ranges for AudioParam
14:11:33 <BillHofmann> bug 391 - Specify nominal ranges for AudioParam
14:12:23 <BillHofmann> Assign to Paul, v1, ready for editing
14:14:37 <BillHofmann> Next bugs: biquad filter issues
14:15:50 <BillHofmann> bugs 426, 427, 428, 429, 430, 431, 432 - refer to audio cookbook, however, the implementations don't match - should we make them match, or make the spec match the implementation
14:21:01 <BillHofmann> recommendation is to make the formula match the implementation
14:23:15 <BillHofmann> mark as ready for editing; should acknowledge audio cookbook
14:23:54 <BillHofmann> bug 436 - handling attributes set to null
14:26:18 <shepazu> Audio EQ cookbook is at http://shepazu.github.io/Audio-EQ-Cookbook/audio-eq-cookbook.html
14:26:52 <shepazu> ACTION: rtoyg to add acknowledgment to Robert Bristow-Johnson in Web Audio API spec
14:26:52 <trackbot> Error finding 'rtoyg'. You can review and register nicknames at <http://www.w3.org/2011/audio/track/users>.
14:27:23 <shepazu> ACTION: raymond to add acknowledgment to Robert Bristow-Johnson in Web Audio API spec
14:27:23 <trackbot> Created ACTION-120 - Add acknowledgment to robert bristow-johnson in web audio api spec [on Raymond Toy - due 2015-06-08].
14:33:40 <BillHofmann> proposed action - values will be nullable, but can only assume the value of null in their inited state, otherwise will throw InvalidStateError
14:35:15 <BillHofmann> bug 444
14:36:49 <BillHofmann> proposed: just document - should be oncomplete last
14:37:23 <BillHofmann> bug 447
14:37:47 <BillHofmann> (Difference in loudness from different implementation)
14:39:46 <BillHofmann> mozilla now aligns; but how to spec?
14:43:37 <BillHofmann> Joe: notes issue 91 specifies the behavior we want, pretty much
14:45:42 <BillHofmann> Joe: proposes re-titling to "Define built-in oscillator output more carefully"
14:47:09 <BillHofmann> Joe: output of a built-in oscillator must be equivalent to the output of an equivalent PeriodicWave with normalization.
14:49:00 <BillHofmann> bug 452
14:51:05 <BillHofmann> resolution: fix spec to cite MediaStreamAudioDestinationNote as well...
14:51:38 <BillHofmann> bug 457 - Clarify behavior when DelayNode output is connected back to delayTime AudioParam, creating a cycle
14:55:06 <BillHofmann> resolution: will mute
14:56:15 <BillHofmann> Joe - propose punt to v.Next
14:56:17 <GitHubBot> GitHubBot has joined #audio
14:56:17 <GitHubBot> [web-midi-api] cwilso pushed 1 new commit to gh-pages: https://github.com/WebAudio/web-midi-api/commit/439c238bd40470b9902a7689729bf6a3b3cf120e
14:56:17 <GitHubBot> web-midi-api/gh-pages 439c238 Chris Wilson: Fixes #149.
14:56:18 <GitHubBot> GitHubBot has left #audio
14:57:20 <BillHofmann> bug 459 - ChannelMergerNode in a cycle has unspecified behaviour
14:57:41 <BillHofmann> resolution: already fixed...
14:57:47 <BillHofmann> (per cwilso)
14:58:56 <shepazu> scribenick: shepazu
14:59:48 <shepazu> Topic: issue 460
15:00:10 <shepazu> cwilso: there's a error, it doesn't increase in real time
15:01:04 <shepazu> ... it represents the current time of the next block to be processed (the beginning of the next rendering content frame)
15:01:18 <shepazu> ... let's just remove the word "realtime"
15:01:46 <shepazu> joe: that's what #460 says
15:02:18 <shepazu> ... this is covered in #381
15:03:19 <shepazu> ... marked as ready for editing, in v1
15:03:38 <shepazu> Topic: issue 464
15:03:58 <shepazu> ChrisL: accept as invalid state error
15:04:09 <shepazu> Topic: issue 465
15:04:47 <shepazu> joe: where are we on this? the topic changes
15:05:02 <shepazu> joe: do we just change them from floats to doubles?
15:05:29 <shepazu> ... there's loss in precision going back and forth
15:06:28 <shepazu> rtoyg: the issue is that internally in Chrome, we use floats.... you can't evaluate it in JS, making it hard to write a test for it
15:06:48 <shepazu> padenot: I think we have the same behavior in FF
15:07:09 <shepazu> ... seems a bit brutal to just use double, but...
15:07:54 <shepazu> rtoyg: then implementations need to handle it better, and that could be disruptive
15:08:18 <shepazu> joe: WebIDL could be a double, but specs internally could use floats
15:08:48 <shepazu> BillHofmann: might set wrong expectations to developers
15:09:00 <shepazu> ... on precision
15:09:48 <shepazu> padenot: instead of flooring, do we round?
15:10:01 <shepazu> ... having the param the same as the sample makes sense to me
15:10:21 <shepazu> ChrisL: flip it the other way around
15:11:09 <shepazu> ... say the interface type is floats, but say that implementations may promote to double for improved precision of intermediate calculations
15:11:48 <shepazu> joe: leaving it as float makes sense ...
15:12:40 <shepazu> ... note to developers that if they are going to go between integer-based units, converting between sample rates and times, to use round rather than truncation
15:12:49 <shepazu> rtoyg: not sure that solves the issue
15:13:20 <shepazu> [quibbling]
15:13:47 <shepazu> rtoyg: when you look at in isolation, yes... but...
15:14:48 <shepazu> rtoyg: I'll look at it closer, but good enough for now
15:15:07 <shepazu> resolved
15:15:59 <shepazu> Topic: issue 468
15:17:01 <shepazu> ChrisL: this is a great case of wide and substative review
15:17:18 <shepazu> s/substative/substantive/
15:17:51 <shepazu> joe: I think this a good issue, but it's a big change, so maybe move to v2?
15:18:12 <shepazu> cwilso: this is absolutely a valid use case
15:18:31 <shepazu> ... whether we want to implement it as doing FFT before and after, not sure
15:18:40 <shepazu> ... maybe we do need an FFT library
15:19:31 <shepazu> ... maybe someone should prototype it as demonstration
15:19:33 <ChrisL> see http://chinpen.net/webaudiofftperf/
15:20:01 <shepazu> ... that pipeline is indeed complicated
15:20:38 <shepazu> ... the performance test was using scriptprocessor, because it couldn't do anything else
15:21:19 <shepazu> .... this needs to be done in audioworkers
15:22:37 <shepazu> cwilso: step 1 should be implementing a native FFT library that works on arrays, not audio specific
15:23:18 <shepazu> ... along the lines of the Extensible Web
15:23:48 <shepazu> Topic: issue 469
15:24:05 <shepazu> joe: I understand why people want this
15:24:19 <shepazu> ... but it seems a bit underdefined
15:24:31 <shepazu> ... seems like it's about the performance of the graph
15:24:57 <shepazu> BillHofmann: sigh
15:25:18 <shepazu> .... would you spec exposing a latency? seems like it lead to a loop
15:25:30 <shepazu> ... maybe we should limit latency?
15:26:23 <shepazu> ChrisL: who are we doing this for? (discussed different use cases)
15:26:55 <shepazu> cwilso: I didn't mention in the bug that they are using a compressor
15:27:19 <shepazu> joe: doesn't make sense to talk about latency in this way if the output is different than the input
15:27:49 <shepazu> ... seems like a non-issue with respect to what they mention, should it be separate issues?
15:28:18 <shepazu> ... the root is that the original spec talked a lot about spacialization, and not enough about delay
15:31:46 <shepazu> ChrisL: i hadn't know there was this much latency in the graph
15:31:57 <shepazu> padenot: it's because of lookahead
15:32:48 <shepazu> shepazu: should we note this in the spec?
15:35:52 <shepazu> [debate about value of warning devs]
15:36:38 <shepazu> joe: maybe we could have proper latency reporting in v2?
15:36:56 <shepazu> rtoyg: not sure that latency in compressor is even computable
15:39:03 <shepazu> [discussion of pros, cons, and constraints]
15:39:18 <hongchan> hongchan has joined #audio
15:40:18 <shepazu> ChrisL: maybe a note to say, "when latency is important, developers should calculate this offline"
15:49:31 <hongchan> hongchan has joined #audio
15:58:38 <BillHofmann> BillHofmann has joined #audio
16:03:56 <padenot> Topic: 470, already assigned to padenot
16:04:05 <padenot> Topic: 471
16:04:22 <padenot> padenot: maybe it's a equal-power vs. equalpower issue ?
16:05:31 <padenot> cwilso: I'm current fixing it, it's just an editorial issue
16:05:40 <Zakim> Zakim has left #audio
16:05:55 <ghaudiobot> [web-audio-api] cwilso pushed 1 new commit to gh-pages: https://github.com/WebAudio/web-audio-api/commit/d9286b46c4feff2bf6f4b2df3f5e414d9abc4a41
16:05:55 <ghaudiobot> web-audio-api/gh-pages d9286b4 Chris Wilson: Fixes #471
16:06:26 <padenot> padenot: it should not be hyphenated
16:06:32 <padenot> Topic: 474
16:07:09 <ghaudiobot> [web-audio-api] cwilso pushed 1 new commit to gh-pages: https://github.com/WebAudio/web-audio-api/commit/3392038eb9b207ae23f30f97baae3aab20da01f6
16:07:09 <ghaudiobot> web-audio-api/gh-pages 3392038 Chris Wilson: Fix hyphenated instances of "equal-power" (part of #471)
16:08:24 <ghaudiobot> [web-audio-api] cwilso pushed 1 new commit to gh-pages: https://github.com/WebAudio/web-audio-api/commit/f608f6c2c27f46c1f6865e997b8673e055caf619
16:08:24 <ghaudiobot> web-audio-api/gh-pages f608f6c Chris Wilson: Further hyphenation fixes (#471)
16:11:04 <padenot> joe: Resolution: AudioWorkerNode are implementing postMessage, the behaviour should follow the definition of postMessage
16:11:36 <padenot> padenot: we will need input from people working on script, and proabably worker
16:12:47 <padenot> Topic: 477
16:13:02 <padenot> Resolution: "just fix it"
16:13:08 <padenot> Topic: 478
16:14:26 <padenot> Resolution: it's already fixed upstream, we can just close it
16:14:33 <padenot> Topic: 480
16:16:45 <padenot> cwilso: We should probably use NotSupportedError here, when setting the channel count to something bigger than the supperted range
16:16:59 <padenot> Topic: 481
16:18:15 <padenot> Resolution, closing it without change, see comment
16:18:28 <padenot> Topic: 482
16:19:45 <padenot> cwilso: the .value is never going to give you something interesting here
16:20:27 <padenot> joe: is the intrinsic value a concept that is defined when the audio is connected to an AudioParam
16:20:39 <padenot> cwilso: it's probably defined as "largely useless"
16:20:47 <padenot> cwilso: (reading spec...)
16:21:33 <padenot> joe: there is another issue that capture the fact that .value needs to be defined, does it returns the "computed value"
16:22:21 <padenot> joe: reading 2.5.3, audio connected don't change .value
16:22:41 <padenot> joe: neither scheduled parameters nor audio input change the .value
16:22:59 <padenot> cwilso: not true, it depends how you read it
16:23:19 <padenot> joe: we could say "it does not matter"
16:23:29 <padenot> cwilso: it's described in the section where it says "when read...."
16:23:58 <padenot> joe: if we leave the spec alone, this particular issue is resolved, but we have the issue about "intrinsic value" meaning
16:25:24 <padenot> Topic: 486
16:26:47 <padenot> joe: I can tell you from using this API that computing a time for when it reach 0 is hard
16:32:41 <padenot> ... lengthy discussion about the fact that this is hard ...
16:33:29 <shepazu_> shepazu_ has joined #audio
16:38:43 <ChrisL> ChrisL has joined #audio
16:39:16 <ChrisL> ChrisL has joined #audio
16:40:07 <rtoyg_m> rtoyg_m has joined #audio
16:42:35 <rtoyg_m_> rtoyg_m_ has joined #audio
16:42:46 <shepazu> shepazu has joined #audio
16:43:54 <padenot> ... more discussion ...
16:44:42 <padenot> Resolution: we just point to setTargetAtTime, because this is the wrong method for the job
16:44:54 <padenot> Topic: 489
16:47:18 <padenot> Resolution: we leave it like that for v1, because it's a crappy API anyways, and works is gonna happen in v.next
16:47:45 <padenot> in the meantime, more useful information can be put in the error console
16:51:55 <padenot> cwilso: it's already specced, just close this
16:54:53 <padenot> Topic: 496
16:55:11 <padenot> cwilso: we can't fix that in v1. MediaRecorder is at the wrong level of abstraction for now
16:55:30 <cwilso> s/wrong/possibly wrong/
16:56:08 <padenot> joe: it's gonna be addressed in the future by reworking encoding and decoding APIs
16:56:20 <padenot> Topic: 497
16:57:36 <padenot> Resolution: This is just editorial
16:57:40 <padenot> Topic 503
17:01:15 <padenot> Resolution: if you cancel...(), then you should be able to go back to using .value
17:06:02 <padenot> also, setting the value calls cancelScheduledValues() under the hood
17:06:20 <padenot> Topic: 504
17:07:11 <padenot> "just do what the comment says"
17:07:28 <padenot> Topic 506:
17:12:21 <padenot> "that's not webaudio's problem"
17:12:33 <padenot> Topic 509:
17:12:53 <padenot> resolution is to switch to a-rate. engines might perform optimizations
17:19:36 <colinbdclark> colinbdclark has joined #audio
17:50:24 <hongchan> hongchan has joined #audio
17:55:03 <kawai> kawai has joined #audio
17:56:10 <rtoyg_m> rtoyg_m has joined #audio
18:04:21 <rtoyg_m> Issue https://github.com/WebAudio/web-audio-api/issues/510
18:05:37 <todd> todd has joined #audio
18:05:45 <shepazu> shepazu has joined #audio
18:06:06 <rtoyg_m> joe: Complicated issue with some confusion from the developer
18:07:20 <rtoyg_m> joe: Shows the complexity of automation methods.  We have discussed exposing a way to get automation values.
18:07:57 <rtoyg_m> padenot: Suggests reimplementing audioparams in JS.
18:08:41 <rtoyg_m> padenot: Or function to probe automation value
18:10:27 <hongchan> hongchan has joined #audio
18:11:22 <rtoyg_m> padenot: holdValueAtTime makes some sense to hold the value.
18:11:42 <rtoyg_m> cwilso: Isn't that the same as cancelValueAtTime?
18:14:06 <rtoyg_m> joe: What does cancelValueAtTime actually do?
18:14:29 <rtoyg_m> cwilso: Technically doesn't work with setTargetValue.
18:14:40 <rtoyg_m> all: It's completely broken.
18:16:45 <rtoyg_m> cwilso: Developer basically has to implement automation to figure out what happens and adjust parameters appropriately.  See DJ app.
18:19:56 <hongchan> hongchan has joined #audio
18:20:11 <rtoyg_m> cwilso: cancelScheduledValues needs to be updated to handle setTargetValue
18:20:28 <rtoyg_m> joe: What do people what really want?
18:21:11 <rtoyg_m> cwilso:  We should give an example of ADSR to show how to do it.  But basically requires devs to compute automation.
18:21:40 <rtoyg_m> joe: Close this issue since it doesn't add any new info not already covered elsewhere.
18:22:35 <rtoyg_m> https://github.com/WebAudio/web-audio-api/issues/512
18:23:19 <todd> todd has joined #audio
18:24:43 <rtoyg_m> padenot: Can't have everything.
18:25:36 <rtoyg_m> joe: Clarify spec to hint that ABSN can be used for any length, not just short samples.
18:26:03 <rtoyg_m> https://github.com/WebAudio/web-audio-api/issues/513
18:28:03 <rtoyg_m> cwilso: jer's answer is correct.
18:29:16 <rtoyg_m> Next issue: all dezippering issues.
18:30:49 <rtoyg_m> See https://github.com/WebAudio/web-audio-api/issues/76 for primary issues
18:36:55 <rtoyg_m> joe: Resolve 76 that dezippering is equivalent to setTargetAtTime, with some differences.
18:42:39 <rtoyg_m> joe: Add new issue that describes how dezippering applies on initial value.
18:44:23 <rtoyg_m> joe: Example:  If value is 2, and node starts, no dezippering should happen, and value should start at 2.
18:46:02 <rtoyg_m> rtoyg_m: What about gain nodes that don't have "start" times.
18:46:14 <rtoyg_m> joe:  Wouldn't it be poetic to remove dezippering again?
18:47:34 <rtoyg_m> rtoyg_m: Might break things.
18:48:55 <rtoyg_m> cwilso: But what would we break?  Needs to be explained better.
18:49:44 <hongchan> hongchan has joined #audio
18:51:46 <rtoyg_m> joe:  Document the current state so we don't break anything and tell people how to do what they want.
18:55:45 <rtoyg_m> cwilso: It happens in bad places (freq/detune on oscillator).
18:56:34 <rtoyg_m> cwilso: Don't bake in current state if we want a spec to last 10 years.
18:57:16 <rtoyg_m> cwilso: Document where we want it or complete remove it.  Volume (gain) control is really the only place it makes sense.
19:00:47 <rtoyg_m> joe:  Dezippering is too complicated to actually explain.
19:01:11 <rtoyg_m> shepazu: If we remove dezippering, is there any place we really need it?
19:01:19 <rtoyg_m> padenot: delay time needs it.
19:01:52 <ChrisL> see glowport, here:  http://whitefiles.org/rws/r02.htm
19:02:00 <ChrisL> s/port/pot/
19:02:12 <rtoyg_m> padenot: FF does dezippering only for delay time.
19:03:44 <mdjp> note - the glowpot must have been just before my time at the bbc
19:04:21 <rtoyg_m> shepazu: Should we just tell people how to do smooth volume changes?
19:05:58 <rtoyg_m> BillHofmann: LIkes the removal of dezippering.
19:07:42 <rtoyg_m> joe: Not knowing when and how dezippering is a burden on developers.
19:08:52 <rtoyg_m> cwilso: Remove everywhere including delay node.  Need to tell developers what todo to make params changes smoothly.
19:09:43 <rtoyg_m> shepazu: Any cost to implementations?
19:10:02 <rtoyg_m> rtoyg_m, cwilso, padenot Very minor implementation cost.
19:10:24 <hongchan> hongchan has joined #audio
19:15:43 <shepazu_> shepazu_ has joined #audio
19:30:38 <hongchan> hongchan has joined #audio
19:31:26 <ChrisL> scribenick: ChrisL
19:32:21 <ChrisL> joe: proposed tail-between-legs retraction of previous retraction on dezippering
19:32:36 <ChrisL> ... needs revision on delaynode
19:32:57 <ChrisL> (group): really? gone
19:33:17 <ChrisL> OH" this is about how it is implemented, not how it is made"
19:34:23 <ChrisL> rtoyg: chrome will change to take into account removal of dezippering (and magical treatment of first value)
19:34:56 <todd> todd has joined #audio
19:35:29 <ChrisL> joe: volunteers to do the spec edit, removing auto dizippering, how to use automation, and effect  on delayNode
19:35:58 <ChrisL> BillHofmann: (reads from spec on delayNode)
19:36:26 <ChrisL> close all the dizippering issues
19:37:04 <ChrisL> BillHofmann: if users are not complaining, and ff does no dezippering, that means it is not an issue
19:37:42 <ChrisL> mdjp: (points out parked PR 393 to remove dezippering, already)
19:38:42 <ChrisL> Topic: Walk through issues marked as Need WG Review
19:38:58 <ChrisL> joe: https://github.com/WebAudio/web-audio-api/issues?q=is%3Aopen+is%3Aissue+label%3A%22Needs+WG+review%22
19:40:36 <ChrisL> (agenda reshuffle discussion)
19:41:19 <ChrisL> self.congratulate() - method not found
19:41:26 <joe> https://github.com/WebAudio/web-audio-api/issues?q=is%3Aopen+is%3Aissue+label%3A%22Needs+WG+review%22
19:42:13 <ChrisL> https://github.com/WebAudio/web-audio-api/issues/532
19:42:38 <todd_> todd_ has joined #audio
19:43:17 <ChrisL> padenot: starting to impl audio worker. dev knowing a lot about workers pointed out many issues
19:43:30 <todd> todd has joined #audio
19:43:50 <ChrisL> ... compared web worker and audio worker spec. listed issues, quoting worker spec
19:44:23 <ChrisL> padenot: conept of worker tightly coupled to OS thread
19:44:55 <ChrisL> ... base inteerface has a ton of stuf, most of which we don't want as its on the audio thread
19:45:26 <ChrisL> cwilso: like what?
19:45:33 <ChrisL> padenot: fetch, promise, setInterval for example
19:45:51 <ChrisL> cwilso: can audio processing threads fork?
19:46:07 <ChrisL> padenot: do not want jiting on audio thread
19:47:11 <ChrisL> ChrisL: sounds like a base class of an execution context
19:47:23 <ChrisL> padenot: yes, but that is a big project
19:48:04 <ChrisL> cwilso: yes, audio workers in a shared thread, not a high startup performance cpost or memory cost.
19:48:27 <ChrisL> ... long lived, file transfers is an issue
19:48:46 <ChrisL> padenot: postMessage with transferrable
19:49:20 <ChrisL> cwilso: how to have code sitting that knows to do this
19:49:47 <ChrisL> padenot: no traditional event loop. execute between blocks
19:50:29 <ChrisL> padenot: queue that is emptied at th beginning of each block
19:51:02 <ChrisL> cwilso: avoid setTimeout etc. postMessage requires an event loop
19:51:57 <ChrisL> cwilso: architectual layering here is a proble (as roc pointed out long ago)
19:52:46 <ChrisL> ... lack input ad output device access. workers we tried to build on top in a web worker with other stuff pushed into it.
19:53:07 <ChrisL> ... would not lke to see a totally different beast for that
19:53:27 <ChrisL> cwilso: stilll issue of jiting code
19:53:39 <shepazu> shepazu has joined #audio
19:54:18 <ChrisL> padenot: a few blockers here
19:54:53 <ChrisL> joe: expensive things clearly identified, like setup costs
19:55:09 <todd> todd has joined #audio
19:55:13 <hongchan> hongchan has joined #audio
19:55:31 <ChrisL> ... assume yyou make a global factory with the expensive startup. node creation and running is light
19:55:56 <ChrisL> ... lack a way for worker script to indicate setup complete, resady to go
19:56:00 <ChrisL> padenot: promises
19:56:23 <ChrisL> (do we, don't we)
19:56:34 <ChrisL> cwilso: promise inside global scope
19:57:03 <ChrisL> joe: script cant do stuff asynchronously
19:58:08 <ChrisL> cwilso: method called to get a promise that resolves when it is ready
19:58:55 <ChrisL> joe: lack a  mechanism for deferring own return
19:59:43 <ChrisL> cwilso: (deja vu on complexity analysis)
20:00:28 <ChrisL> cwilso: design not done yet
20:00:59 <ChrisL> cwilso: can take feedback to TAG, see what they think
20:01:59 <ChrisL> padenot: beyond scope of webaudio. similar to graphics synced on vsync
20:02:21 <ChrisL> ... video workers
20:03:14 <ChrisL> BillHofmann: sounds like a base class indeed. do we know exactly what we are asking?
20:04:20 <ChrisL> padenot: to multiplex on the same thread, this stops it being as lightweight as
20:04:40 <ChrisL> joe: needs to not be tied to a single thread
20:05:12 <ChrisL> joe: running in a same thread is not visible
20:05:30 <ChrisL> padenot: deterministic
20:06:17 <ChrisL> joe: doset up outside then handoff the thread
20:06:47 <ChrisL> cwilso: concerned about hit from new audio worker
20:07:33 <ChrisL> BillHofmann: feel like nodeing a new script node that triggers computation
20:07:50 <ChrisL> cwilso: eval jit is in thread
20:08:04 <ChrisL> padenot: how to spec it is the main issue
20:08:20 <cwilso> s/eval just is in thread/eval jit MAY be in thread?/
20:09:01 <ChrisL> padenot: so we need to talk to others
20:09:37 <ChrisL> padenot: setTimeOut?
20:09:54 <ChrisL> cwilso: needs to look at current time
20:10:21 <ChrisL> ... needs postMessage
20:10:41 <ChrisL> cwilso: (fft library)
20:11:01 <ChrisL> joe: who will take this further
20:11:17 <ChrisL> cwilso: happy to continue
20:11:47 <ChrisL> padenot: set of requirements is non-traditional
20:12:44 <ChrisL> https://github.com/WebAudio/web-audio-api/issues/445
20:13:27 <ChrisL> joe: getUserMedia is input only, not io
20:13:37 <ChrisL> https://github.com/WebAudio/web-audio-api/issues/445
20:14:06 <ChrisL> joe: returns a device ID
20:14:23 <ChrisL> (points to spec)
20:15:33 <ChrisL> joe: filtering depends on anti-fingerrinting issues
20:15:57 <ChrisL> ... also no channelcount, hedphones etc
20:16:48 <ChrisL> BillHofmann: they are clearly ommitting, not forgetting
20:17:22 <ChrisL> joe: permissionsare not clear, do get a decent default
20:18:11 <ChrisL> shepazu: requiring permissions is fine
20:18:42 <ChrisL> joe: ca get an array f thsese, inc channel cont
20:19:04 <ChrisL> (several) its an opaque ID
20:19:45 <ChrisL> joe: need a few more attributes, to count
20:20:22 <ChrisL> joe: if access has been granted, they are ok with adding extra info
20:20:50 <ChrisL> joe: need access to at leasdty one device before getting a list
20:21:20 <ChrisL> joe: (example, asking for headphoes)
20:22:12 <ChrisL> mdjp: connecting to default device
20:22:27 <ChrisL> BillHofmann: persistent means
20:22:40 <ChrisL> shepazu: session persistent
20:23:52 <ChrisL> BillHofmann: makes multiple devices worthless
20:24:42 <ChrisL> (catch 22 enumeration). constraint structure
20:25:00 <ChrisL> ... is missing for audio
20:25:46 <ChrisL> (reads persistent ids section)
20:26:37 <ChrisL> shepazu: needs a clear, public blog post to establish the use cases
20:27:56 <ChrisL> joe: their LC is underway
20:29:01 <ChrisL> shepazu: accessibility requirement to access one of several audio devices used for different purposes or with different characteristics
20:30:50 <ChrisL> shepazu: point out the input and output assymmetry
20:31:44 <ChrisL> padenot: people are doing all sorts of stuff with webrtc if you give them access
20:36:18 <ChrisL> BillHofmann: will help on the blog post aspect
20:41:19 <hongchan> hongchan has joined #audio
20:42:33 <ChrisL> https://github.com/WebAudio/web-audio-api/issues/419
20:44:25 <ChrisL> joe: current tme does not change in realtime, its an advance time on eext audio quantum
20:44:48 <ChrisL> ... want to relate it to a performance, change dom, visual change and be synced to audio
20:44:57 <ChrisL> .. need mapping functions
20:45:12 <ChrisL> cwilso: its estimation, not strict mapping
20:45:35 <ChrisL> ... driven by separate crystal so changes over time wrt another thread
20:45:46 <ChrisL> padenot: drift
20:46:36 <ChrisL> cwilso: wanted a window performance now related to current time in audio context
20:46:52 <ChrisL> ... a pair of times, one in each system
20:47:03 <ChrisL> joe: maybe safer, with pause and resume
20:47:20 <ChrisL> so do current time only
20:48:08 <ChrisL> cwilso: asking with window performance time maps to a given audio thread time
20:49:24 <ChrisL> padenot: (bluetooth can add huge drift)
20:49:48 <ChrisL> joe: add new audio context attribute for current time, and dom timestamp corresponding to current time
20:49:58 <ChrisL> ... so we can do the math and make estimates
20:50:56 <ChrisL> cwilso: need to smooth jitter to estimate latency
20:52:38 <ChrisL> simplify issue 12 by removing the dom timestamp, and point the oter isue at issue 12
20:53:47 <ChrisL> padenot: intervals reasonably safe
20:55:08 <ChrisL> (discussion of jitter reduction)
20:55:57 <ChrisL> cwilso: like a getter not an attribute
20:56:01 <ChrisL> joe: readonly
20:56:25 <ChrisL> padenot: another absolute time, not a latency quantity. derive it
20:56:52 <ChrisL> padenot: good enough synchronization
20:58:59 <ChrisL> padenot: normally, you get a consistent number when asking for time. good for start methods, get a consistent result when starting a lot of them
20:59:07 <ChrisL> this would be different, less stable
21:01:03 <ChrisL> padenot: mostly needed for audio and video sync. playhead offset, needs cross thread calculation. a latency that evolves onthe main thread is not easy to use
21:02:19 <ChrisL> joe: so impl difficulties to advance in real time
21:03:51 <ChrisL> cwilso: chris had this in a build to smooth jitter but did not expose it
21:04:22 <hongchan> hongchan has joined #audio
21:05:31 <ChrisL> joe: how di i get the dom hires timestamp?
21:05:38 <ChrisL> padenot: add the latency
21:07:03 <ChrisL> padenot: even with bluetooth and external usb soundcards you get a decent number
21:07:29 <ChrisL> joe: 250ms latency common on android
21:09:05 <ChrisL> https://github.com/WebAudio/web-audio-api/issues/340 updated
21:10:34 <ChrisL> kawai: we can use thys to sync with MIDI host?
21:11:02 <ChrisL> cwilso: yes. but currentTime does not advance uniformly. WebMIDI uses performance time
21:11:10 <ChrisL> s/thys/this/
21:12:47 <ChrisL> https://github.com/WebAudio/web-audio-api/issues/335
21:12:58 <ChrisL>  progressCallback in decodeAudioData #335
21:13:29 <ChrisL> joe: propose a per-decode object rather than adding more stuff to promises
21:14:58 <ChrisL> cwilso: this is a crappy api lets not fix it but instead add a better one later. it has an update as least, and is light
21:15:13 <ChrisL> ... in the long run, avoid it
21:15:47 <ChrisL> jernoble: Ick!
21:16:26 <ChrisL> padenot: byte buffer to audio/video is complex. so one member that says appendData, wemiss something
21:17:05 <ChrisL> ... (wonders about resampling, concludes it is fine)
21:18:20 <ChrisL> joe: progress event seems like a medusa. dispatch off the audio context (see the thread)
21:19:08 <ChrisL> joe: the progress event will need more machinery
21:19:34 <ChrisL> padenot: was full fledged deconing and encoding api, its needed, don't want a short term hack
21:20:05 <ChrisL> padenot: want a reall full featured api in v.2
21:20:35 <ChrisL> s/decon/decod/
21:20:56 <ChrisL> cwilso: get a good overall progress with some smoothing
21:21:20 <ChrisL> padenot: not clear we need a stopgap. its fine for v.1
21:21:35 <ChrisL> cwilso: decodes lengthy on mobile, is the issue
21:22:06 <ChrisL> (infinite spinners vs. progress bars, UX for the win)
21:22:50 <ChrisL> joe: agree on defer and do much better one on v2
21:22:57 <ChrisL> padenot: better layering too
21:24:31 <ChrisL> cwilso: can live with
21:25:27 <ChrisL> padenot: can hook to a completion promise?
21:25:50 <ChrisL> cwilso: no, fetch fires progress events to itself
21:26:33 <ChrisL> cwilso: give it an object, and it fires progress events to it
21:26:49 <ChrisL> cwilso: needs a new event target
21:28:07 <ChrisL> joe: creating ab object that will patch events?
21:28:19 <ChrisL> cwilso: its a target, not a dispatcher
21:28:27 <ChrisL> joe: how do you make one?
21:28:50 <ChrisL> cwilso: lots of things are event targets (gives long list)
21:29:44 <ChrisL> joe: using callbacks all over this, do that here too? was good suggestion but
21:30:44 <ChrisL> cwilso: lots of ways to do this
21:31:06 <ChrisL> rrsagent, make minutes
21:31:06 <RRSAgent> I have made the request to generate http://www.w3.org/2015/06/01-audio-minutes.html ChrisL
21:41:37 <ChrisLilley> ChrisLilley has joined #audio
01:01:26 <hongchan> hongchan has joined #audio
01:03:42 <hongchan> hongchan has joined #audio
01:17:32 <shepazu> shepazu has joined #audio
01:18:07 <kawai> kawai has joined #audio
01:21:35 <shepazu> shepazu has joined #audio
04:28:15 <rtoyg_m> rtoyg_m has joined #audio