IRC log of audio on 2013-07-11
Timestamps are in UTC.
- 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