16:52:13 RRSAgent has joined #audio 16:52:13 logging to http://www.w3.org/2014/12/04-audio-irc 16:52:15 RRSAgent, make logs world 16:52:15 Zakim has joined #audio 16:52:17 Zakim, this will be 28346 16:52:17 ok, trackbot; I see RWC_Audio()12:00PM scheduled to start in 8 minutes 16:52:18 Meeting: Audio Working Group Teleconference 16:52:18 Date: 04 December 2014 16:52:32 Chair: mdjp 16:53:04 Agenda+ Update on Web Audio Conference 16:53:13 Agenda+ Prioritising and resolving issues now categorised for V1 16:55:21 RWC_Audio()12:00PM has now started 16:55:28 +??P0 16:55:59 zakim, P0 is me 16:55:59 sorry, mdjp, I do not recognize a party named 'P0' 16:56:06 zakim, ??P0 is me 16:56:06 +mdjp; got it 16:56:22 rrsagent, pointer? 16:56:22 See http://www.w3.org/2014/12/04-audio-irc#T16-56-22 16:56:28 agenda? 17:00:44 + +1.650.253.aaaa 17:00:55 +Doug_Schepers 17:01:00 rtoyg_m_ has joined #audio 17:01:01 +joe 17:01:09 +BillHofmann 17:01:22 joe has joined #audio 17:01:33 zakim, who is here? 17:01:33 On the phone I see mdjp, +1.650.253.aaaa, Doug_Schepers, joe, BillHofmann 17:01:35 On IRC I see joe, rtoyg_m_, Zakim, RRSAgent, rtoyg_m, colinbdclark, paul___irish, slightlyoff, shepazu, rtoyg, padenot, mdjp, cwilso, Domenic, trackbot 17:01:36 hongchan has joined #audio 17:01:39 zakim, aaaa is me 17:01:39 +cwilso; got it 17:01:49 zakim, cwilso has rtoyg 17:01:49 +rtoyg; got it 17:01:54 zakim, cwilso has hongchan 17:01:54 +hongchan; got it 17:01:57 BillHofmann has joined #audio 17:02:10 zakim, pick a victim 17:02:10 Not knowing who is chairing or who scribed recently, I propose mdjp 17:02:19 zakim, pick a victim 17:02:19 Not knowing who is chairing or who scribed recently, I propose Doug_Schepers 17:02:46 zakim, pick a victim 17:02:46 Not knowing who is chairing or who scribed recently, I propose BillHofmann 17:03:22 It's impossible to hear you... (maybe it's me) 17:03:29 nope, us too 17:03:46 Better now. 17:05:40 Zakim, who's noisy? 17:05:51 shepazu, listening for 10 seconds I heard sound from the following: mdjp (62%), cwilso (64%), Doug_Schepers (16%) 17:05:59 Zakim, mute cwilso 17:06:01 cwilso should now be muted 17:06:01 perhaps others should mute 17:06:05 zakim, unmute cwilso 17:06:05 cwilso should no longer be muted 17:06:59 scribenick: joe 17:07:07 q+ to say there are still a few issues on https://github.com/WebAudio/web-audio-api/issues?q=is%3Aopen+is%3Aissue+label%3A%22Needs+WG+review%22 17:07:44 cwilso: there are still a few issues left to productively discuss. want to briefly talk about the multi input/outout AudioWorker concept before writing more 17:08:09 matt: if that's an issue you want to look at we can look at that 17:08:36 cwilso: The previous link identifies issues that still need WG review 17:09:08 cwilso: I was on the hook for a proposal for multiple inputs and outputs and I think it's for the best if we separate a multiple-I/O AudioWorker API from a single-I/O AudioWorker 17:09:19 mdjp: so we're talking about multiple hardware? 17:09:29 cwilso: we're talking about nodes with multiple input and output ports 17:09:34 q+ 17:10:00 cwilso: we really want AudioWorker to address this but the incremental complexity added by multiple ports is considerable 17:10:20 mdjp: so proposal is to split into a simpler API for single ports, more complex API for multiple 17:11:06 cwilso, you wanted to say there are still a few issues on https://github.com/WebAudio/web-audio-api/issues?q=is%3Aopen+is%3Aissue+label%3A%22Needs+WG+review%22 17:11:10 ack joe 17:12:22 joe: could we start with the more complex version 17:13:30 mdjp: can we get that proposal together in time for next telco? 17:13:39 cwilso: on 12/18? 17:13:46 cwilso: yes I can probably pull that together 17:13:55 mdjp: we will add for next agenda 17:14:04 https://github.com/WebAudio/web-audio-api/issues?q=is%3Aopen+is%3Aissue+label%3A%22Needs+WG+review%22 17:14:48 mdjp: looking at the issues that need WG review now 17:14:58 mdjp: issue #421 17:15:09 https://github.com/WebAudio/web-audio-api/issues/421 17:16:15 cwilso: proposal is that duration is alias to start + stop 17:16:17 q+ 17:16:23 ack joe 17:16:52 joe: support cwilso's proposal for disposition even though breaking change 17:17:15 cwilso: the only other thing it could mean for looped buffers is "nothing" which would be weird 17:17:24 mute cwilso 17:17:38 unmute cwilso 17:17:41 mute cwilso 17:17:46 mdjp: if you had a start and a stop point, duration would mean how long the loop plays for 17:17:58 q+ 17:17:58 unmute cwilso 17:18:13 q- 17:18:28 mute cwilso 17:18:36 q+ 17:18:41 ack joe 17:18:58 unmute cwilso 17:19:18 mute cwilso 17:19:25 cwilso: stop + duration interaction can also occur in any node 17:19:27 unmute cwilso 17:19:31 not just a looped one 17:19:37 mute cwilso 17:19:46 mdjp: do we agree with cwilso's proposition at the top of this issue? 17:19:58 I agree with my proposition. :) 17:19:59 mdjp: any opposition to this? 17:20:15 unmute cwilso 17:20:16 mdjp: we'll go with that proposal then. 17:20:21 mute cwilso 17:20:28 cwilso: I'll record that. 17:20:31 https://github.com/WebAudio/web-audio-api/issues/335 17:21:32 unmute cwilso 17:21:57 mute cwilso 17:21:57 cwilso: I haven't checked with TAG on recommended pattern yet so let's skip for now 17:22:04 https://github.com/WebAudio/web-audio-api/issues/304 17:22:48 unmute cwilso 17:23:57 q+ 17:24:35 cwilso: if I create a merger node that I want to use for 5.1, with only subwoofer output, I should be able to just connect that one channel. Today doing that causes the merger to think it has mono input 17:24:53 cwilso: the only downside is that this is a breaking change 17:25:03 ack joe 17:25:07 mute cwilso 17:25:07 cwilso: this won't break any setup in which all the channels are there 17:25:33 unmute cwilso 17:25:56 mute cwilso 17:26:29 mdjp: sounds like it's not an optimal solution right now 17:26:41 unmute cwilso 17:27:35 cwilso: proposal won't break code that is explicitly connecting things to all inputs. we should do this. 17:27:37 q+ 17:27:41 mute cwilso 17:29:14 joe: agree. visibility of GC of incoming connections also a big problem 17:29:26 yes 17:29:29 mdjp: cwilso can you please update ticket 17:29:41 q- 17:29:55 https://github.com/WebAudio/web-audio-api/issues/110 17:31:45 cwilso: let's do nothing 17:32:11 cwilso: we could do an O(n) pass over buffer to clamp these to zero but it's kind of a waste of time. 17:32:14 I agree 17:32:20 agree. 17:32:25 mdjp: I agree also. Does anyone object? 17:32:34 zakim, mute cwilso 17:32:35 cwilso was already muted, cwilso 17:32:35 Does that require some sort of documentation? 17:32:44 mdjp: resolutin is that we will close this issue 17:32:52 zakim, unmute cwilso 17:32:52 cwilso should no longer be muted 17:33:11 cwilso: we can say that Inf and NaN may have unpredicability 17:33:13 "behavior is undefined"? 17:33:16 I think it would be good to say that 17:33:32 cwilso: I'll put it in spec 17:33:33 zakim, mute cwilso 17:33:33 cwilso should now be muted 17:33:41 mdjp, we heard nothing 17:34:00 mdjp: we'll resolve to do nothing but document that these values have no defined result 17:34:16 https://github.com/WebAudio/web-audio-api/issues/108 17:35:00 zakim, unmute cwilso 17:35:00 cwilso should no longer be muted 17:36:38 cwilso: I don't know that it's going to be easy to chane the progression of currentTime and make every single mod in the main thread transactional 17:37:21 cwilso: crogers said that if you need to do complex atomic changes to the graph, and it's critical that they happen together, then one should have some sort of lock mechanism 17:37:47 q+ propose defer this - this is really a call for transactions. 17:37:51 cwilso: personally I don't think that is necessary. we already have pretty good queuing of path changes 17:38:59 cwilso: propose deferring to v2. 17:39:36 zakim, mute cwilso 17:39:36 cwilso should now be muted 17:39:48 cwilso: I don't think we can fix everything about observation and modification to be atomic without a lot of effort 17:40:03 zakim, unmute cwilso 17:40:03 cwilso should no longer be muted 17:40:09 mdjp: if this was moved to v2, would we actually resolve this then? 17:40:25 cwilso: my personal preference is that we wait to see if it ever does become a real problem 17:41:56 zakim, mute cwilso 17:41:56 cwilso should now be muted 17:42:04 mdjp: 331 disappears if we address 108 17:42:20 mdjp: general feeling is move this to v2? 17:42:28 I think we move to v2 17:42:40 yep 17:42:42 mdjp: no objections, it will be moved to v2 17:42:42 zakim, unmute cwilso 17:42:42 cwilso should no longer be muted 17:42:50 zakim, mute cwilso 17:42:50 cwilso should now be muted 17:42:58 q+ 17:43:22 ack joe 17:44:03 zakim, unmute cwilso 17:44:03 cwilso should no longer be muted 17:44:27 joe: are there any good opportunities to change the API so that nonatomic changes are less likely to cause glitches? 17:44:59 zakim, mute cwilso 17:44:59 cwilso should now be muted 17:45:09 https://github.com/WebAudio/web-audio-api/issues/79 17:45:13 cwilso: not really. I don't think we should try to temporarily clean up a problem that we'll have to institute a wide ranging topdown solution for 17:46:13 zakim, unmute cwilso 17:46:13 cwilso should no longer be muted 17:46:28 mdjp: is there a doppler aspect to this that is now invlidated by other decisions we made ealier? 17:46:42 cwilso: that's a different notion of doppler which related only to PannerNode 17:47:05 cwilso: this is more of a question of what happens to samples already in the delay buffer while the delay time is actively changing. 17:47:21 cwilso: I think under some circumstances it would even play backwards. 17:48:12 cwilso: I think simply stating that delayTime is a-rate defines it as being smooth 17:48:34 cwilso: in absence of de-zippering maybe we should just remove the words "smoothly" 17:48:59 I completely agree. I don't see that there's something that needs fixing 17:49:04 zakim, mute cwilso 17:49:04 cwilso should now be muted 17:49:27 zakim, unmute cwilso 17:49:27 cwilso should no longer be muted 17:49:28 mdjp: if it didn't make the transition smoothly what would happen? 17:49:29 q+ 17:50:29 cwilso: once dezippering is removed, there would be a glitch but it can be remedied by using setTargetAtTime() 17:51:08 ack joe 17:51:09 cwilso: we're basically saying that because it's a-rate, it will work naturally when there is a continuous transition in the param value 17:52:17 cwilso: there were 2-3 places in the spec where crogers had used the word "smoothly", mostly in conjunction with de-zippering. 17:52:43 cwilso: suggested wording: "if you are changing delayTime.value, you REALLY MIGHT WANT TO USE DEZIPPERING" (caps due to scribe) 17:53:00 mdjp: so this is giving advice to users 17:53:18 mdjp: perhaps we should just remove that altogether 17:53:50 cwilso: let's remove the language from the spec since param is a-rate. Recommend that user may have a click or glitch when changing delayTime unless setTarget or ramp is used 17:53:57 zakim, mute cwilso 17:53:57 cwilso should now be muted 17:54:00 cwilso: will put into bug 17:54:12 https://github.com/WebAudio/web-audio-api/issues/80 17:54:42 I believe we should keep it even though extra to avoid breaking anything 17:54:59 mdjp: chris, what were the questions here? 17:55:02 zakim, unmute cwilso 17:55:02 cwilso should no longer be muted 17:55:41 cwilso: AudioBuffer exposes a duration in seconds which can be trivially calculated from sample rate plus data length. 17:56:49 cwilso: because it's already there we should just leave it in and move on even though it's not completely clean 17:56:57 zakim, mute cwilso 17:56:57 cwilso should now be muted 17:56:58 mdjp: agreed lets not have a breaking change 17:57:06 I agree let's close this 17:57:28 q+ 17:58:09 mdjp: we're now going to have a WG-led session on Wed. AM at web audio conference 17:58:16 mdjp: I'll send out a 1-pager 17:58:21 q+ 17:58:28 mdjp: about what we might want participants to talk about in that session 17:58:43 ack joe 17:59:08 zakim, unmute cwilso 17:59:08 cwilso should no longer be muted 17:59:35 joe: will #113 proposal for next telco include script scoping and multiple channels 17:59:45 zakim, mute cwilso 17:59:45 cwilso should now be muted 17:59:50 ack shepazu 17:59:51 cwilso: maybe 18:00:13 zakim, unmute cwilso 18:00:13 cwilso should no longer be muted 18:00:17 shepazu: cwilso, I know you're busy. I assume that if people come to you with strawman proposals for spec ideas, would that be OK? 18:00:34 cwilso: I'm more than happy to have other people do work here 18:00:40 zakim, mute cwilso 18:00:40 cwilso should now be muted 18:01:01 shepazu: I wanted to comment briefly on mdjp's idea about the Wed AM meeting in Paris. I love when we have opportunity to get feedback from our users. 18:01:31 shepazu: if anyone has spare 15 minutes to help me code up an example I have some questions about the web audio API 18:01:36 zakim, unmute cwilso 18:01:36 cwilso should no longer be muted 18:01:52 cwilso: join the audio-dev IRC channel! 18:01:57 -BillHofmann 18:02:04 -cwilso 18:02:09 -Doug_Schepers 18:02:19 -joe 18:02:31 -mdjp 18:02:32 RWC_Audio()12:00PM has ended 18:02:32 Attendees were mdjp, +1.650.253.aaaa, Doug_Schepers, joe, BillHofmann, rtoyg, hongchan 18:20:45 rtoyg_m has joined #audio 18:38:17 hongchan has joined #audio