15:40:51 <RRSAgent> RRSAgent has joined #audio
15:40:51 <RRSAgent> logging to http://www.w3.org/2013/07/11-audio-irc
15:40:53 <trackbot> RRSAgent, make logs world
15:40:53 <Zakim> Zakim has joined #audio
15:40:55 <trackbot> Zakim, this will be 28346
15:40:55 <Zakim> ok, trackbot; I see RWC_Audio()12:00PM scheduled to start in 20 minutes
15:40:56 <trackbot> Meeting: Audio Working Group Teleconference
15:40:56 <trackbot> Date: 11 July 2013
15:41:11 <olivier> Agenda: http://lists.w3.org/Archives/Public/public-audio/2013JulSep/0066.html
15:41:16 <olivier> Agenda+ Removing #OldNames ( http://lists.w3.org/Archives/Public/public-audio/2013AprJun/0634.html )
15:41:22 <olivier> Agenda+  Fixing Race Conditions ( http://lists.w3.org/Archives/Public/public-audio/2013AprJun/thread.html#msg644 and http://lists.w3.org/Archives/Public/public-audio/2013JulSep/thread.html#msg10 )
15:41:27 <olivier> Agenda+ web midi issue 2 ( https://github.com/WebAudio/web-midi-api/issues/2 )
15:41:31 <olivier> Agenda+ Review recent web midi changes (Promises)
15:57:14 <crogers> crogers has joined #audio
15:57:28 <jussi> jussi has joined #audio
15:58:18 <ehsan> ehsan has joined #audio
15:58:30 <Zakim> RWC_Audio()12:00PM has now started
15:58:37 <Zakim> +[Mozilla]
15:59:31 <Zakim> +[IPcaller]
15:59:36 <olivier> zakim, IPcaller is me
15:59:36 <Zakim> +olivier; got it
15:59:39 <Zakim> +cwilso
15:59:44 <chrislowis> olivier: I'm here. Just dialing in.
15:59:55 <olivier> chrislowis: good!
15:59:55 <chrislowis> zakim, what's the code?
15:59:55 <Zakim> the conference code is 28346 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), chrislowis
15:59:59 <jernoble> jernoble has joined #audio
16:00:07 <Zakim> +giri
16:00:10 <Zakim> + +1.408.772.aaaa
16:00:23 <gmandyam> gmandyam has joined #audio
16:00:27 <olivier> zakim, aaaa is jernoble
16:00:27 <Zakim> +jernoble; got it
16:00:28 <jernoble> zakim, aaaa is me
16:00:29 <Zakim> sorry, jernoble, I do not recognize a party named 'aaaa'
16:00:40 <olivier> zakim, who is making noise?
16:00:45 <Zakim> +[IPcaller]
16:00:50 <Zakim> olivier, listening for 10 seconds I heard sound from the following: olivier (2%), cwilso (22%)
16:00:53 <padenot> me
16:01:01 <Zakim> +[IPcaller.a]
16:01:04 <olivier> zakim, IPcaller is padenot
16:01:05 <Zakim> +padenot; got it
16:01:21 <Zakim> + +1.510.334.aabb
16:01:24 <cwilso> zakim, who is making noise?
16:01:34 <olivier> zakim, IPcaller.a is chrislowis
16:01:34 <Zakim> +chrislowis; got it
16:01:36 <Zakim> cwilso, listening for 10 seconds I heard sound from the following: olivier (40%), cwilso (8%), padenot (11%)
16:02:02 <olivier> zakim aabb is crogers
16:02:07 <olivier> zakim, aabb is crogers
16:02:07 <Zakim> +crogers; got it
16:02:19 <olivier> zakim, agenda?
16:02:19 <Zakim> I see 4 items remaining on the agenda:
16:02:20 <Zakim> 1. Removing #OldNames ( http://lists.w3.org/Archives/Public/public-audio/2013AprJun/0634.html ) [from olivier]
16:02:20 <Zakim> 2. Fixing Race Conditions ( http://lists.w3.org/Archives/Public/public-audio/2013AprJun/thread.html#msg644 and
16:02:20 <Zakim> ... http://lists.w3.org/Archives/Public/public-audio/2013JulSep/thread.html#msg10 ) [from olivier]
16:02:21 <Zakim> 3. web midi issue 2 ( https://github.com/WebAudio/web-midi-api/issues/2 ) [from olivier]
16:02:22 <Zakim> 4. Review recent web midi changes (Promises) [from olivier]
16:03:19 <olivier> zakim, take up agendum 1
16:03:19 <Zakim> agendum 1. "Removing #OldNames ( http://lists.w3.org/Archives/Public/public-audio/2013AprJun/0634.html )" taken up [from olivier]
16:03:21 <chrislowis> scribeNick: chrislowis
16:03:43 <chrislowis> olivier: we have a full agenda. We may not cover it all.
16:03:46 <joe> joe has joined #audio
16:04:01 <Zakim> +??P15
16:04:01 <Zakim> + +1.617.600.aacc
16:04:28 <olivier> zakim, P15 is jussi
16:04:28 <Zakim> sorry, olivier, I do not recognize a party named 'P15'
16:04:33 <olivier> zakim, ??P15 is jussi
16:04:33 <Zakim> +jussi; got it
16:04:37 <olivier> zakim, aacc is joe
16:04:37 <Zakim> +joe; got it
16:04:46 <olivier> http://lists.w3.org/Archives/Public/public-audio/2013AprJun/0666.html
16:05:13 <chrislowis> We discussed, and mostly agreed on what to do with the section on removed/deprecated names.
16:05:31 <chrislowis> I'd like some agreement on when and how this section will be removed, given that there is consensus on removing it.
16:05:42 <chrislowis> If you think there's a need to plan this, please come forward.
16:05:52 <chrislowis> Otherwise, I'll just give crogers the action to remove it.
16:06:35 <chrislowis> crogers: I think at this time of transition while devs are adapting their code, it'll be helpful to keep it in there.
16:06:42 <olivier> (section is https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#OldNames )
16:07:02 <chrislowis> crogers: although it's true we have most of the information on the mozilla wiki, I think it'd be valuable to keep it there.
16:07:15 <Zakim> -chrislowis
16:07:19 <chrislowis> crogers: for now, but I agree that we'll probably remove it when it comes to that time.
16:07:40 <Zakim> +[IPcaller]
16:07:50 <chrislowis> Zakim: IPcaller is me
16:07:57 <chrislowis> zakim, IPcaller is me
16:07:57 <Zakim> +chrislowis; got it
16:08:35 <chrislowis> ehsan: I don't have a strong feeling about removing it now - as long as it doesn't make it into any final publication
16:09:12 <chrislowis> olivier: not hearing a strong opinion to remove it asap, so I'll defer to crogers to make the call as weditor about when to remove it.
16:09:21 <olivier> ACTION: crogers to remove the #OldNames section from the webaudio spec
16:09:22 <trackbot> Created ACTION-64 - Remove the #OldNames section from the webaudio spec [on Chris Rogers - due 2013-07-18].
16:09:29 <olivier> zakim, close agendum
16:09:29 <Zakim> I don't understand 'close agendum', olivier
16:09:34 <olivier> zakim, close this agendum
16:09:34 <Zakim> agendum 1 closed
16:09:35 <Zakim> I see 3 items remaining on the agenda; the next one is
16:09:35 <Zakim> 2. Fixing Race Conditions ( http://lists.w3.org/Archives/Public/public-audio/2013AprJun/thread.html#msg644 and
16:09:35 <Zakim> ... http://lists.w3.org/Archives/Public/public-audio/2013JulSep/thread.html#msg10 ) [from olivier]
16:09:46 <olivier> zakim, take up agendum 2
16:09:46 <Zakim> agendum 2. "Fixing Race Conditions ( http://lists.w3.org/Archives/Public/public-audio/2013AprJun/thread.html#msg644 and
16:09:48 <Zakim> ... http://lists.w3.org/Archives/Public/public-audio/2013JulSep/thread.html#msg10 )" taken up [from olivier]
16:09:58 <chrislowis> olivier: onto the more meaty "fixing the race condition issue".
16:10:32 <chrislowis> olivier: ehsan noted that people who have an opinion (roc, in particular), cannot be on the call, so we may not make a decision today. But a quick chat on "how" we're going to solve this, at least.
16:10:46 <chrislowis> olivier: there's been a lot of discussion, but there's not a clear consensus emerging.
16:11:00 <chrislowis> olivier: there has been suggestions that demos showing behaviour one way or another would help.
16:11:16 <chrislowis> olivier: can people give some options to how we might get to consensus.
16:11:25 <olivier> zakim, mute chrislowis
16:11:25 <Zakim> chrislowis should now be muted
16:11:41 <marcosc> marcosc has joined #audio
16:11:58 <chrislowis> /me: olivier apologies
16:12:29 <chrislowis> ehsan: if we don't want to make any changes in the IDL, I think the only option we have is to neuter the buffers.
16:12:54 <chrislowis> ehsan: if we're willing to accept changes to the IDL, then jer's proposal about making ArrayBuffer's immutable would fix the problem.
16:13:21 <chrislowis> ehsan: there's also the performance issue that crogers raised, I think we all agree we want to avoid memcopy's as much as possible
16:13:28 <gmandyam> q+
16:13:41 <chrislowis> ehsan: but I don't think I have enough information on whether the proposals we have would be acceptable.
16:13:48 <olivier> q+ crogers
16:13:52 <chrislowis> ehsan: I'd like to ask crogers to share some more information on that.
16:13:58 <olivier> ack gmandyam
16:14:02 <chrislowis> olivier: thanks ehsan, first to gmandyam on the Q
16:14:22 <chrislowis> gmandyam: are we talking about defining an extension to the ArrayBuffer type and making that immutable
16:14:36 <olivier> ack crogers
16:14:36 <chrislowis> ehsan: my mistake, I meant the AudioBuffer, not ArrayBuffer.
16:15:08 <chrislowis> crogers: I'd like to give my overview of what I think the situation is:
16:15:45 <chrislowis> crogers: firstly roc pointed out a security bug in our implementation, which we have a fix for, I don't think there's anything really "race-y" about this in the normal context of the API.
16:16:14 <chrislowis> crogers: it's true that it can be if you immediately modify the buffer, but that is an extremely contrived example.
16:16:21 <olivier> q+
16:16:49 <jernoble> jernoble has joined #audio
16:17:01 <chrislowis> crogers: we have over 2 years of experience from developers, both novice and experienced, and we have never seen any problems around race conditions with this issue.
16:17:26 <chrislowis> olivier: you're saying it is possible to get race conditions, but is very contrived. A question: would it ever be desirable to allow it to happen at all?
16:17:55 <chrislowis> crogers: normally, you wouldn't want to tempt it into a race condition as such. There would be no predicatable effect that you'd want to hit with this.
16:18:35 <chrislowis> olivier: my second question, and bear in mind I'm not up to speed on the detail, you say there would be a negative impact to fixing this (unlikely) race condition. Do you have any way to showcase that negative impact?
16:19:34 <chrislowis> crogers: it depends if we are talking about copying buffers of data? If we are, they can be quite large (audio sprites, with lots of audio samples in a single buffer, for example). It's bad practice then to be in a situation where these have to be copied.
16:19:53 <chrislowis> olivier: ehsan mentioned that we agree that memcopy is something we want to avoid.
16:20:11 <ehsan> q+
16:20:13 <chrislowis> crogers: ok. The second point: getChannelData is designed for simplicity for devs to get access to the data.
16:20:32 <olivier> ak ehsan
16:20:36 <olivier> ack ehsan
16:20:45 <chrislowis> crogers: any changes that require the dev to understand when things are copied by adding bells and whistles to the API would be a bad idea.
16:21:23 <chrislowis> ehsan: roc had 2 examples. One that showed an AudioBuffer being modified by calls to getChannelData. The second showed modification of the buffer before sending it to a web worker.
16:21:28 <jussi> q+
16:21:44 <chrislowis> ehsan: I don't believe the second example is contrived: it's something I did myself in the early days of the spec.
16:22:05 <chrislowis> ehsan: just because we haven't heard from developers hitting this problem, doesn't mean it isn't a problem.
16:22:38 <olivier> q- later
16:23:19 <chrislowis> ehsan: if there are edge cases in the API that cause bad effects, there will be people who hit them. While we have the chance, now, to mitigate this we should take this, or it will hurt interoperability. Code might work because of timing issues on my machine, but may not work on another because of a change in hardware, for exampe.
16:23:33 <chrislowis> ehsan: I don't think we can say that this is a problem that won't occur.
16:23:44 <jernoble> q+
16:24:19 <chrislowis> ehsan: the other point about the memcopy situation, by adding a stage where the buffer is neutered.
16:24:23 <olivier> ack jussi
16:24:26 <olivier> q- later
16:24:54 <chrislowis> jussi: I agree with ehsan, we should race conditions, even if the examples are contrived, I don't think race conditions are desirable, even if it's a rare case.
16:25:02 <olivier> ack jer
16:25:05 <chrislowis> jussi: we just want to avoid them in general.
16:25:30 <chrislowis> jernoble: two related comments, when we brought up the neutering code path to our performance team they brought up two issues:
16:25:58 <chrislowis> jernoble: when the JS compiler looks at those ArrayBuffers it can assume that it doesn't change,
16:26:19 <chrislowis> jernoble: they would like us to come up with a solution that doesn't involve neutering.
16:26:25 <ehsan> q+
16:27:15 <olivier> ack me
16:27:20 <chrislowis> jernoble: secondly, it would be unfortunate if memcopy is required in the API, if we could arrange for it that it only happens when people do unusual things, such as modifying a buffer when they get it back, then it might be ok.
16:28:14 <chrislowis> olivier: we need to decide whether we are going to fix this, if so, how we are going to fix this, and *when* we're going to do it.
16:28:25 <jernoble> q+
16:28:44 <chrislowis> olivier: the question of when is important because we want to start to stabalise the API.
16:28:47 <olivier> ack ehsan
16:29:41 <chrislowis> ehsan: I have a question to jernoble about the problem with neutering ArrayBuffers. The only buffer that gets neutered is the one that getChannelData has previously returned. If the normal use case is for that ArrayBuffer to not be modified, is that still a problem?
16:30:30 <olivier> ack jer
16:30:30 <chrislowis> ehsan: I wanted to confirm if under this scenario, it'd still be an issue?
16:31:38 <ehsan> q+
16:31:50 <chrislowis> jernoble: as far as I understand the proposal. It would require a neutering for normal operations, not just in the exceptional ones.
16:32:34 <olivier> zakim, close q
16:32:34 <Zakim> I don't understand 'close q', olivier
16:32:39 <olivier> zakim, close the queue
16:32:39 <Zakim> ok, olivier, the speaker queue is closed
16:32:48 <chrislowis> jernoble: I would like to see a solution that is as reasonable for developers and implementors. That's why I proposed the AudioBuffer solution.
16:33:15 <olivier> ack ehsan
16:33:23 <chrislowis> jernoble: if we were to take a vote on whether we need to fix this right now, put me on the side of not taking it as a big deal for now.
16:33:34 <chrislowis> ehsan: I believe we should address this problem.
16:34:12 <chrislowis> ehsan: on the topic of neutering the AudioBuffers - if we don't do that, we would have to make breaking changes to the API, and we have differing opinions on how big a problem that would be.
16:34:39 <chrislowis> ehsan: If we want to avoid neutering, but believe we must fix this, then we need to make changes to the IDL.
16:35:12 <joe> q+
16:35:24 <olivier> zakim, reopen the queue
16:35:24 <Zakim> ok, olivier, the speaker queue is open
16:35:56 <chrislowis> olivier: I get the feeling we're in a vicious circle here to a certain extent. I think the arguments are clear and have been made very well. I think we need a proposal for how to break the deadlock.
16:36:39 <johnwbyrd> johnwbyrd has joined #audio
16:36:47 <chrislowis> joe: my opinion is that we should make clear that after the effect changes to ArrayBuffer have no defined effect, but that we don't need to explicity prevent the race conditions.
16:37:47 <chrislowis> crogers: ehsan was concerned that there might be a case where something sounded usable on one browser and not on another. I don't think there would be a case where that would be an effect that someone would want to exploit.
16:37:56 <chrislowis> ehsan: between mobile and desktop though?
16:38:53 <chrislowis> crogers: yes, I agree, but I don't see there being any kind of developer code that would be sensible that would "take advantage" of this effect on one browser over another. It's possible, roc wrote it down, but it would just be "wrong code" that would produce unusable results.
16:39:20 <olivier> zakim, close the queue
16:39:20 <Zakim> ok, olivier, the speaker queue is closed
16:39:24 <chrislowis> crogers: for example, using setTimeout to modify a gainNode's gain.value and seeing that it would have different effects on different browsers.
16:40:02 <chrislowis> crogers: this has been out there, and has been used a lot by excited developers, it's true that it's a prefixed version, but we deal with seasoned and experienced developers, and I think that counts for something.
16:40:11 <chrislowis> olivier: I'm going to make 2 proposals here:
16:41:20 <chrislowis> olivier: I get the sense that the burden is on the proponants of change. 1) I'd like a volunteer to find out if someone out there has an opinion on the potential of the problem of race conditions. If there's a w3c position on whether we should address race conditions at all cost, then that's one way out.
16:42:08 <chrislowis> 2) I don't hear consensus that roc's demonstration of the race condition is realistic, is there a more convincing example we could come up with?
16:42:53 <chrislowis> ehsan: I don't believe anyone else, accept crogers and jernoble on this call, agrees that leaving these race conditions in is acceptable. On public-audio everyone agrees it should be removed.
16:43:33 <chrislowis> ehsan: I agree with crogers that it is bad practice to write code like this, but you can't argue that people could come to rely on the race condition without realising it.
16:44:09 <chrislowis> ehsan: you've never seen this kind of condition before, you test it on FF, Chrome on your desktop, and you believe that your code will work everywhere for all time, and that may not be tru.e
16:44:57 <chrislowis> olivier: that's a good point. But what we're dealing with is a risk assessment. We know there is a risk, but we should try to concentrate on how bad the risk is, and what we should do about it to get a resolution to the issue.
16:45:30 <chrislowis> olivier: I do not have a good way forward to balance the risk, the cost of a fix, and the cost of leaving it there.
16:46:08 <chrislowis> ehsan: I do believe that this call is not the right venue to come up with a conclusion on what we should be doing. I don't know what the process should be.
16:46:36 <chrislowis> ehsan: there's two sides to the argument, we disagree with each other, and I don't know how we're going to make progress unfortunately.
16:47:12 <olivier> zakim, close this agendum
16:47:12 <Zakim> agendum 2 closed
16:47:13 <Zakim> I see 2 items remaining on the agenda; the next one is
16:47:13 <Zakim> 3. web midi issue 2 ( https://github.com/WebAudio/web-midi-api/issues/2 ) [from olivier]
16:47:39 <chrislowis> olivier: the typical process is that someone brings an argument that is convincing enough, but that is proving problematic in this case. We've had a good go at it, let's move on for today and carry on on the list, I'll think about it in the meantime.
16:47:51 <olivier> zakim, take up agendum 3
16:47:51 <Zakim> agendum 3. "web midi issue 2 ( https://github.com/WebAudio/web-midi-api/issues/2 )" taken up [from olivier]
16:47:59 <chrislowis> olivier: next agendum. cwilso can we have a summary of where we are on this issue?
16:48:28 <cwilso> https://github.com/WebAudio/web-midi-api/issues/2#issuecomment-20687489
16:48:35 <chrislowis> cwilso: sure, we've shuffled around a few designs, what we've come up with is a map-like concept that will look something like what we have in our build today, but is much more forward-looking in its design.
16:49:53 <chrislowis> olivier: jussi and marcosc, are you happy, or happy enough with the map-like concept?
16:50:22 <chrislowis> jussi: I'm quite happy with the map-like concept, and much happier with it than my original proposal, so I'm glad
16:50:46 <chrislowis> jussi: I think we're coming close to a consensus on this one as well, from what I'm picking up - I'm happy as it's been a long-standing issue.
16:50:57 <chrislowis> olivier: so you need more pairs of eyes looking at it now?
16:51:02 <chrislowis> jussi: yes, I believe so.
16:51:31 <chrislowis> jussi: actually, the biggest concern is getting implementation experience, so the ball is now in implementators court to see how implementable in the real world it is.
16:51:50 <chrislowis> olivier: the current implementation uses the old interface, does it cwilso?
16:52:00 <tobie> tobie has joined #audio
16:52:24 <chrislowis> cwilso: the one in Chrome Canary uses something that's in one of my editor branches, it's not quite at the proposed stage, but it's getting there.
16:52:35 <Zakim> -padenot
16:52:38 <chrislowis> crogers: I'm not sure I understand the API - could you give an overview?
16:52:55 <olivier> what it looks like -> https://github.com/WebAudio/web-midi-api/issues/2#issuecomment-20687489
16:52:56 <chrislowis> cwilso: the easiest way to get up to speed is to go to the github comment link:
16:52:58 <chrislowis> ^^
16:54:03 <chrislowis> cwilso: you can iterate through the values, but you won't use a for loop the way I have it declared with array's you'll populate through it using `for i in`, take a look at jussi's gist for example.
16:54:20 <cwilso> jussi's gist: https://gist.github.com/jussi-kalliokoski/5960415
16:55:05 <cwilso> for ( let [ id, port ] of midiAccess.inputs.items() ) {
16:55:05 <cwilso>     let option = document.createElement('option');
16:55:05 <cwilso>     option.value = id;
16:55:05 <cwilso>     option.innerHTML = port.manufacturer + ' ' + port.name;
16:55:05 <cwilso>     options.selected = !!selectedPort && selectedPort.id === id;
16:55:05 <cwilso>     select.appendChild(option);
16:55:05 <cwilso> }
16:55:15 <johnwbyrd> johnwbyrd has left #audio
16:55:29 <chrislowis> Zakim, who is talking?
16:55:35 <olivier> marcos
16:55:40 <Zakim> chrislowis, listening for 10 seconds I heard sound from the following: [Mozilla] (54%), olivier (19%)
16:56:56 <chrislowis> marcosc: with ES6 we start getting things like map and so on, so we were thinking about things in an ES5 world. What jussi has done is show how the problem can be addressed using ES6 syntax.
16:58:28 <chrislowis> crogers: being an implementor, or one of them, it would be nice to get some developer feedback from webmidi developers. My preference is for something simple, but I can understand the other points of view.
16:59:16 <chrislowis> marcosc: it's been difficult to get much feedback from devs, as we haven't had an implementation for them to play with, now with the canary build we can ask developers for a bit more feedback, which is exciting.
16:59:19 <chrislowis> crogers: I agree.
16:59:53 <chrislowis> crogers: I think the webRTC api has something similar to get audio and video tracks.
17:01:32 <chrislowis> olivier: listing the tracks in the webRTC?
17:01:53 <chrislowis> gmandyam: that has to be possible as they have track ids, some basic "capabilities"
17:02:00 <crogers> https://svn.webkit.org/repository/webkit/trunk/Source/WebCore/Modules/mediastream/MediaStream.idl
17:02:57 <chrislowis> olivier: has there been, in the webRTC group, discussion about how we give developers access to the channels and streams.
17:03:22 <chrislowis> gmandyam: I think I'd agree that what they ended up with in webRTC isn't that elegant.
17:03:46 <cwilso> q+: we're out of time.  I'd like 30 seconds to cover the disposition of other issues.
17:03:51 <chrislowis> gmandyam: but I still can't get the group there to agree about whether cloning results in something stuctured or not.
17:03:56 <cwilso> q+
17:05:06 <chrislowis> crogers: I was just pointing to webRTC as an example, but we should just consider how to access channels etc.
17:05:53 <Zakim> -jernoble
17:06:02 <chrislowis> marcosc: I think now we just need some demos, like we have for web audio, to help get some more feedback.
17:06:21 <chrislowis> crogers: I don't object to the map approach, I'd like to see something simpler, but I don't object.
17:06:43 <olivier> RESOLUTION: there is consensus around the map solution for web midi issue 2
17:06:43 <chrislowis> olivier: then we should record that we've reached consensus around this issue, and move towards getting more feedback.
17:08:27 <chrislowis> cwilso: #77 I'm going to leave open for now.
17:08:34 <olivier> issues for webmidi -> https://gist.github.com/jussi-kalliokoski/5960415
17:08:43 <chrislowis> cwilso: #59 needs an example, I'm going to add one.
17:08:56 <olivier> I meant - https://github.com/WebAudio/web-midi-api/issues?state=open
17:08:58 <chrislowis> cwilso: origin scope needs to go in, I haven't got that in.
17:09:04 <chrislowis> cwilso: #2 is discussed
17:09:13 <chrislowis> cwilso: and virtual ports is marked as a v2 issue.
17:09:27 <chrislowis> cwilso: Any disagreement to those, bring it up on the list.
17:09:38 <chrislowis> olivier: agreed, I'll note those in the summary of this call.
17:09:53 <chrislowis> olivier: and we'll give everyone the week to register disagreement.
17:10:17 <chrislowis> olivier: thanks everyone for participating. We *are* making progress, even if it's not easy. Speak to you all in 2 weeks.
17:10:20 <chrislowis> olivier: adjorned.
17:10:22 <Zakim> -giri
17:10:26 <Zakim> -joe
17:10:27 <Zakim> -[Mozilla]
17:10:29 <Zakim> -jussi
17:10:30 <Zakim> -olivier
17:10:33 <Zakim> -crogers
17:10:34 <Zakim> -cwilso
17:10:39 <olivier> rrsagent, draft minutes
17:10:39 <RRSAgent> I have made the request to generate http://www.w3.org/2013/07/11-audio-minutes.html olivier
17:10:53 <olivier> zakim, bye
17:10:53 <Zakim> leaving.  As of this point the attendees were [Mozilla], olivier, cwilso, giri, +1.408.772.aaaa, jernoble, padenot, +1.510.334.aabb, chrislowis, crogers, +1.617.600.aacc, jussi,
17:10:53 <Zakim> Zakim has left #audio
17:10:57 <Zakim> ... joe
17:11:31 <olivier> s,issues for webmidi -> https://gist.github.com/jussi-kalliokoski/5960415,issues for webmidi -> https://github.com/WebAudio/web-midi-api/issues?state=open,
17:11:39 <olivier> rrsagent, draft minutes
17:11:39 <RRSAgent> I have made the request to generate http://www.w3.org/2013/07/11-audio-minutes.html olivier
17:11:50 <olivier> Chair: olivier
17:11:52 <olivier> rrsagent, draft minutes
17:11:52 <RRSAgent> I have made the request to generate http://www.w3.org/2013/07/11-audio-minutes.html olivier
17:12:12 <olivier> rrsagent, bye
17:12:12 <RRSAgent> I see 1 open action item saved in http://www.w3.org/2013/07/11-audio-actions.rdf :
17:12:12 <RRSAgent> ACTION: crogers to remove the #OldNames section from the webaudio spec [1]
17:12:12 <RRSAgent>   recorded in http://www.w3.org/2013/07/11-audio-irc#T16-09-21