IRC log of audio on 2014-12-04

Timestamps are in UTC.

16:52:13 [RRSAgent]
RRSAgent has joined #audio
16:52:13 [RRSAgent]
logging to
16:52:15 [trackbot]
RRSAgent, make logs world
16:52:15 [Zakim]
Zakim has joined #audio
16:52:17 [trackbot]
Zakim, this will be 28346
16:52:17 [Zakim]
ok, trackbot; I see RWC_Audio()12:00PM scheduled to start in 8 minutes
16:52:18 [trackbot]
Meeting: Audio Working Group Teleconference
16:52:18 [trackbot]
Date: 04 December 2014
16:52:32 [mdjp]
Chair: mdjp
16:53:04 [mdjp]
Agenda+ Update on Web Audio Conference
16:53:13 [mdjp]
Agenda+ Prioritising and resolving issues now categorised for V1
16:55:21 [Zakim]
RWC_Audio()12:00PM has now started
16:55:28 [Zakim]
16:55:59 [mdjp]
zakim, P0 is me
16:55:59 [Zakim]
sorry, mdjp, I do not recognize a party named 'P0'
16:56:06 [mdjp]
zakim, ??P0 is me
16:56:06 [Zakim]
+mdjp; got it
16:56:22 [mdjp]
rrsagent, pointer?
16:56:22 [RRSAgent]
16:56:28 [mdjp]
17:00:44 [Zakim]
+ +1.650.253.aaaa
17:00:55 [Zakim]
17:01:00 [rtoyg_m_]
rtoyg_m_ has joined #audio
17:01:01 [Zakim]
17:01:09 [Zakim]
17:01:22 [joe]
joe has joined #audio
17:01:33 [cwilso]
zakim, who is here?
17:01:33 [Zakim]
On the phone I see mdjp, +1.650.253.aaaa, Doug_Schepers, joe, BillHofmann
17:01:35 [Zakim]
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]
hongchan has joined #audio
17:01:39 [cwilso]
zakim, aaaa is me
17:01:39 [Zakim]
+cwilso; got it
17:01:49 [cwilso]
zakim, cwilso has rtoyg
17:01:49 [Zakim]
+rtoyg; got it
17:01:54 [cwilso]
zakim, cwilso has hongchan
17:01:54 [Zakim]
+hongchan; got it
17:01:57 [BillHofmann]
BillHofmann has joined #audio
17:02:10 [cwilso]
zakim, pick a victim
17:02:10 [Zakim]
Not knowing who is chairing or who scribed recently, I propose mdjp
17:02:19 [mdjp]
zakim, pick a victim
17:02:19 [Zakim]
Not knowing who is chairing or who scribed recently, I propose Doug_Schepers
17:02:46 [mdjp]
zakim, pick a victim
17:02:46 [Zakim]
Not knowing who is chairing or who scribed recently, I propose BillHofmann
17:03:22 [BillHofmann]
It's impossible to hear you... (maybe it's me)
17:03:29 [cwilso]
nope, us too
17:03:46 [rtoyg_m_]
Better now.
17:05:40 [shepazu]
Zakim, who's noisy?
17:05:51 [Zakim]
shepazu, listening for 10 seconds I heard sound from the following: mdjp (62%), cwilso (64%), Doug_Schepers (16%)
17:05:59 [shepazu]
Zakim, mute cwilso
17:06:01 [Zakim]
cwilso should now be muted
17:06:01 [BillHofmann]
perhaps others should mute
17:06:05 [cwilso]
zakim, unmute cwilso
17:06:05 [Zakim]
cwilso should no longer be muted
17:06:59 [joe]
scribenick: joe
17:07:07 [cwilso]
q+ to say there are still a few issues on
17:07:44 [joe]
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 [joe]
matt: if that's an issue you want to look at we can look at that
17:08:36 [joe]
cwilso: The previous link identifies issues that still need WG review
17:09:08 [joe]
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 [joe]
mdjp: so we're talking about multiple hardware?
17:09:29 [joe]
cwilso: we're talking about nodes with multiple input and output ports
17:09:34 [joe]
17:10:00 [joe]
cwilso: we really want AudioWorker to address this but the incremental complexity added by multiple ports is considerable
17:10:20 [joe]
mdjp: so proposal is to split into a simpler API for single ports, more complex API for multiple
17:11:06 [Zakim]
cwilso, you wanted to say there are still a few issues on
17:11:10 [mdjp]
ack joe
17:12:22 [joe]
joe: could we start with the more complex version
17:13:30 [joe]
mdjp: can we get that proposal together in time for next telco?
17:13:39 [joe]
cwilso: on 12/18?
17:13:46 [joe]
cwilso: yes I can probably pull that together
17:13:55 [joe]
mdjp: we will add for next agenda
17:14:04 [mdjp]
17:14:48 [joe]
mdjp: looking at the issues that need WG review now
17:14:58 [joe]
mdjp: issue #421
17:15:09 [mdjp]
17:16:15 [joe]
cwilso: proposal is that duration is alias to start + stop
17:16:17 [joe]
17:16:23 [mdjp]
ack joe
17:16:52 [joe]
joe: support cwilso's proposal for disposition even though breaking change
17:17:15 [joe]
cwilso: the only other thing it could mean for looped buffers is "nothing" which would be weird
17:17:24 [cwilso]
mute cwilso
17:17:38 [cwilso]
unmute cwilso
17:17:41 [cwilso]
mute cwilso
17:17:46 [joe]
mdjp: if you had a start and a stop point, duration would mean how long the loop plays for
17:17:58 [joe]
17:17:58 [cwilso]
unmute cwilso
17:18:13 [joe]
17:18:28 [cwilso]
mute cwilso
17:18:36 [joe]
17:18:41 [mdjp]
ack joe
17:18:58 [cwilso]
unmute cwilso
17:19:18 [cwilso]
mute cwilso
17:19:25 [joe]
cwilso: stop + duration interaction can also occur in any node
17:19:27 [cwilso]
unmute cwilso
17:19:31 [joe]
not just a looped one
17:19:37 [cwilso]
mute cwilso
17:19:46 [joe]
mdjp: do we agree with cwilso's proposition at the top of this issue?
17:19:58 [cwilso]
I agree with my proposition. :)
17:19:59 [joe]
mdjp: any opposition to this?
17:20:15 [cwilso]
unmute cwilso
17:20:16 [joe]
mdjp: we'll go with that proposal then.
17:20:21 [cwilso]
mute cwilso
17:20:28 [joe]
cwilso: I'll record that.
17:20:31 [mdjp]
17:21:32 [cwilso]
unmute cwilso
17:21:57 [cwilso]
mute cwilso
17:21:57 [joe]
cwilso: I haven't checked with TAG on recommended pattern yet so let's skip for now
17:22:04 [mdjp]
17:22:48 [cwilso]
unmute cwilso
17:23:57 [joe]
17:24:35 [joe]
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 [joe]
cwilso: the only downside is that this is a breaking change
17:25:03 [mdjp]
ack joe
17:25:07 [cwilso]
mute cwilso
17:25:07 [joe]
cwilso: this won't break any setup in which all the channels are there
17:25:33 [cwilso]
unmute cwilso
17:25:56 [cwilso]
mute cwilso
17:26:29 [joe]
mdjp: sounds like it's not an optimal solution right now
17:26:41 [cwilso]
unmute cwilso
17:27:35 [joe]
cwilso: proposal won't break code that is explicitly connecting things to all inputs. we should do this.
17:27:37 [joe]
17:27:41 [cwilso]
mute cwilso
17:29:14 [joe]
joe: agree. visibility of GC of incoming connections also a big problem
17:29:26 [cwilso]
17:29:29 [joe]
mdjp: cwilso can you please update ticket
17:29:41 [joe]
17:29:55 [mdjp]
17:31:45 [joe]
cwilso: let's do nothing
17:32:11 [joe]
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 [joe]
I agree
17:32:20 [BillHofmann]
17:32:25 [joe]
mdjp: I agree also. Does anyone object?
17:32:34 [cwilso]
zakim, mute cwilso
17:32:35 [Zakim]
cwilso was already muted, cwilso
17:32:35 [BillHofmann]
Does that require some sort of documentation?
17:32:44 [joe]
mdjp: resolutin is that we will close this issue
17:32:52 [cwilso]
zakim, unmute cwilso
17:32:52 [Zakim]
cwilso should no longer be muted
17:33:11 [joe]
cwilso: we can say that Inf and NaN may have unpredicability
17:33:13 [BillHofmann]
"behavior is undefined"?
17:33:16 [joe]
I think it would be good to say that
17:33:32 [joe]
cwilso: I'll put it in spec
17:33:33 [cwilso]
zakim, mute cwilso
17:33:33 [Zakim]
cwilso should now be muted
17:33:41 [joe]
mdjp, we heard nothing
17:34:00 [joe]
mdjp: we'll resolve to do nothing but document that these values have no defined result
17:34:16 [mdjp]
17:35:00 [cwilso]
zakim, unmute cwilso
17:35:00 [Zakim]
cwilso should no longer be muted
17:36:38 [joe]
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 [joe]
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 [BillHofmann]
q+ propose defer this - this is really a call for transactions.
17:37:51 [joe]
cwilso: personally I don't think that is necessary. we already have pretty good queuing of path changes
17:38:59 [joe]
cwilso: propose deferring to v2.
17:39:36 [cwilso]
zakim, mute cwilso
17:39:36 [Zakim]
cwilso should now be muted
17:39:48 [joe]
cwilso: I don't think we can fix everything about observation and modification to be atomic without a lot of effort
17:40:03 [cwilso]
zakim, unmute cwilso
17:40:03 [Zakim]
cwilso should no longer be muted
17:40:09 [joe]
mdjp: if this was moved to v2, would we actually resolve this then?
17:40:25 [joe]
cwilso: my personal preference is that we wait to see if it ever does become a real problem
17:41:56 [cwilso]
zakim, mute cwilso
17:41:56 [Zakim]
cwilso should now be muted
17:42:04 [joe]
mdjp: 331 disappears if we address 108
17:42:20 [joe]
mdjp: general feeling is move this to v2?
17:42:28 [joe]
I think we move to v2
17:42:40 [cwilso]
17:42:42 [joe]
mdjp: no objections, it will be moved to v2
17:42:42 [cwilso]
zakim, unmute cwilso
17:42:42 [Zakim]
cwilso should no longer be muted
17:42:50 [cwilso]
zakim, mute cwilso
17:42:50 [Zakim]
cwilso should now be muted
17:42:58 [joe]
17:43:22 [mdjp]
ack joe
17:44:03 [cwilso]
zakim, unmute cwilso
17:44:03 [Zakim]
cwilso should no longer be muted
17:44:27 [joe]
joe: are there any good opportunities to change the API so that nonatomic changes are less likely to cause glitches?
17:44:59 [cwilso]
zakim, mute cwilso
17:44:59 [Zakim]
cwilso should now be muted
17:45:09 [mdjp]
17:45:13 [joe]
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 [cwilso]
zakim, unmute cwilso
17:46:13 [Zakim]
cwilso should no longer be muted
17:46:28 [joe]
mdjp: is there a doppler aspect to this that is now invlidated by other decisions we made ealier?
17:46:42 [joe]
cwilso: that's a different notion of doppler which related only to PannerNode
17:47:05 [joe]
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 [joe]
cwilso: I think under some circumstances it would even play backwards.
17:48:12 [joe]
cwilso: I think simply stating that delayTime is a-rate defines it as being smooth
17:48:34 [joe]
cwilso: in absence of de-zippering maybe we should just remove the words "smoothly"
17:48:59 [joe]
I completely agree. I don't see that there's something that needs fixing
17:49:04 [cwilso]
zakim, mute cwilso
17:49:04 [Zakim]
cwilso should now be muted
17:49:27 [cwilso]
zakim, unmute cwilso
17:49:27 [Zakim]
cwilso should no longer be muted
17:49:28 [joe]
mdjp: if it didn't make the transition smoothly what would happen?
17:49:29 [joe]
17:50:29 [joe]
cwilso: once dezippering is removed, there would be a glitch but it can be remedied by using setTargetAtTime()
17:51:08 [mdjp]
ack joe
17:51:09 [joe]
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 [joe]
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 [joe]
cwilso: suggested wording: "if you are changing delayTime.value, you REALLY MIGHT WANT TO USE DEZIPPERING" (caps due to scribe)
17:53:00 [joe]
mdjp: so this is giving advice to users
17:53:18 [joe]
mdjp: perhaps we should just remove that altogether
17:53:50 [joe]
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 [cwilso]
zakim, mute cwilso
17:53:57 [Zakim]
cwilso should now be muted
17:54:00 [joe]
cwilso: will put into bug
17:54:12 [mdjp]
17:54:42 [joe]
I believe we should keep it even though extra to avoid breaking anything
17:54:59 [joe]
mdjp: chris, what were the questions here?
17:55:02 [cwilso]
zakim, unmute cwilso
17:55:02 [Zakim]
cwilso should no longer be muted
17:55:41 [joe]
cwilso: AudioBuffer exposes a duration in seconds which can be trivially calculated from sample rate plus data length.
17:56:49 [joe]
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 [cwilso]
zakim, mute cwilso
17:56:57 [Zakim]
cwilso should now be muted
17:56:58 [joe]
mdjp: agreed lets not have a breaking change
17:57:06 [joe]
I agree let's close this
17:57:28 [joe]
17:58:09 [joe]
mdjp: we're now going to have a WG-led session on Wed. AM at web audio conference
17:58:16 [joe]
mdjp: I'll send out a 1-pager
17:58:21 [shepazu]
17:58:28 [joe]
mdjp: about what we might want participants to talk about in that session
17:58:43 [mdjp]
ack joe
17:59:08 [cwilso]
zakim, unmute cwilso
17:59:08 [Zakim]
cwilso should no longer be muted
17:59:35 [joe]
joe: will #113 proposal for next telco include script scoping and multiple channels
17:59:45 [cwilso]
zakim, mute cwilso
17:59:45 [Zakim]
cwilso should now be muted
17:59:50 [mdjp]
ack shepazu
17:59:51 [joe]
cwilso: maybe
18:00:13 [cwilso]
zakim, unmute cwilso
18:00:13 [Zakim]
cwilso should no longer be muted
18:00:17 [joe]
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 [joe]
cwilso: I'm more than happy to have other people do work here
18:00:40 [cwilso]
zakim, mute cwilso
18:00:40 [Zakim]
cwilso should now be muted
18:01:01 [joe]
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 [joe]
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 [cwilso]
zakim, unmute cwilso
18:01:36 [Zakim]
cwilso should no longer be muted
18:01:52 [joe]
cwilso: join the audio-dev IRC channel!
18:01:57 [Zakim]
18:02:04 [Zakim]
18:02:09 [Zakim]
18:02:19 [Zakim]
18:02:31 [Zakim]
18:02:32 [Zakim]
RWC_Audio()12:00PM has ended
18:02:32 [Zakim]
Attendees were mdjp, +1.650.253.aaaa, Doug_Schepers, joe, BillHofmann, rtoyg, hongchan
18:20:45 [rtoyg_m]
rtoyg_m has joined #audio
18:38:17 [hongchan]
hongchan has joined #audio