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 http://www.w3.org/2014/12/04-audio-irc
- 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]
- +??P0
- 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]
- See http://www.w3.org/2014/12/04-audio-irc#T16-56-22
- 16:56:28 [mdjp]
- agenda?
- 17:00:44 [Zakim]
- + +1.650.253.aaaa
- 17:00:55 [Zakim]
- +Doug_Schepers
- 17:01:00 [rtoyg_m_]
- rtoyg_m_ has joined #audio
- 17:01:01 [Zakim]
- +joe
- 17:01:09 [Zakim]
- +BillHofmann
- 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 https://github.com/WebAudio/web-audio-api/issues?q=is%3Aopen+is%3Aissue+label%3A%22Needs+WG+review%22
- 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]
- q+
- 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 https://github.com/WebAudio/web-audio-api/issues?q=is%3Aopen+is%3Aissue+label%3A%22Needs+WG+review%22
- 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]
- https://github.com/WebAudio/web-audio-api/issues?q=is%3Aopen+is%3Aissue+label%3A%22Needs+WG+review%22
- 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]
- https://github.com/WebAudio/web-audio-api/issues/421
- 17:16:15 [joe]
- cwilso: proposal is that duration is alias to start + stop
- 17:16:17 [joe]
- q+
- 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]
- q+
- 17:17:58 [cwilso]
- unmute cwilso
- 17:18:13 [joe]
- q-
- 17:18:28 [cwilso]
- mute cwilso
- 17:18:36 [joe]
- q+
- 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]
- https://github.com/WebAudio/web-audio-api/issues/335
- 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]
- https://github.com/WebAudio/web-audio-api/issues/304
- 17:22:48 [cwilso]
- unmute cwilso
- 17:23:57 [joe]
- q+
- 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]
- q+
- 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]
- yes
- 17:29:29 [joe]
- mdjp: cwilso can you please update ticket
- 17:29:41 [joe]
- q-
- 17:29:55 [mdjp]
- https://github.com/WebAudio/web-audio-api/issues/110
- 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]
- agree.
- 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]
- https://github.com/WebAudio/web-audio-api/issues/108
- 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]
- yep
- 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]
- q+
- 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]
- https://github.com/WebAudio/web-audio-api/issues/79
- 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]
- q+
- 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]
- https://github.com/WebAudio/web-audio-api/issues/80
- 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]
- q+
- 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]
- q+
- 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]
- -BillHofmann
- 18:02:04 [Zakim]
- -cwilso
- 18:02:09 [Zakim]
- -Doug_Schepers
- 18:02:19 [Zakim]
- -joe
- 18:02:31 [Zakim]
- -mdjp
- 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