Audio Working Group Teleconference -- 14 Mar 2013

<olivier> trackbot, start meeting

<trackbot> Date: 14 March 2013

<olivier> Scribe: chrislowis

OfflineAudioContext / Memory footprint

olivier: Let's start. Joe could you summarise the discussion so far?

joe: I know someone asked whether the OfflineAudioContext approach had a problem out of the box

<olivier> context - http://lists.w3.org/Archives/Public/public-audio/2013JanMar/0395.html and thread

joe: due to a problem buffering the entire audio stream into memory.
... crogers responded on the list that it works ok at the moment. But is there a problem to be solved?

crogers: for a couple of minutes most machines can take, but at the moment it's taking 20Mb/minute, so for 30minutes of rendering it's a serious chunk of memory
... one way to work around this is to have some kind of periodic optional callback to write out the rendering chuck by chunk
... or write it out to a server periodically.

joe: that makes sense. Would it be possible to use a null destination and a script processor node to achieve the same thing.
... in other words, does the api need an OfflineAudioContext at all?

crogers: the script processor node runs in the main (pot. a worker thread), so in the case where you don't want the buffers one at atime it'll be much more inefficient to do this.
... whereas the OfflineAudioContext will do this more efficiently in a separate thread.

joe: I see the point. The scriptprocessornode is intended for realtime generation of samples, where as offline audio context would want to do its work in much bigger chunks.. is that the thinking?

crogers: yes, something like that. Also the OfflineAudioContext may be able to run faster than real time.
... using the scriptprocessornode in this way might be a bit more clunky.

joe: shall I put this in a bug then?

crogers: yes please.

olivier: could you put it in a bug so we can track this.

oliver: can you add a link to http://lists.w3.org/Archives/Public/public-audio/2013JanMar/0395.html too?

crogers: one thing about the OfflineAudioContext is that it is quite essential to the tests we use in webkit.
... I'd like to spend some time talking about testing at the face to face.

Focus of the upcoming f2f

olivier: we will do that.

<olivier> http://www.w3.org/2011/audio/wiki/F2F_Mar_2013

olivier: A quick chat then about the face to face.
... this is a link to our wiki with a proposed agenda.
... it's a bit of a straw man, which balances i) web audio vs web midi and ii) issue discussion vs testing
... does the balance look right on the agenda?

crogers: I was hoping we could go through the spec, almost line by line, and get some really fast edits in the spec.

olivier: that's a great idea. I'm thinking for testing, how do we get a first list of features? So one thing we could do, while oing through the spec someone can create a list of things to test.

crogers: I think that's worth a try. We have 80 or so automated tests, so maybe we could go through those and see how those tests work.
... so we can see what the feasibility is for making those test-harness neutral and sharing them.

olivier: on the subject of testing, we've been discussing how to make the testing as practical as possible.
... chrislowis has started looking at the harness, with the idea of allowing anyone to contribute tests. I feel that a session where everyone trys to write a test might make things a bit less daunting.
... thoughts?

tmichel: two things I wanted to mention. The first was coverage

<olivier> (RFC keywords)

tmichel: I've identified some RFC keywords which we need to look.
... other tests rely on the prose of the spec, and we should try and identify those.
... I agree that we should have an introduction on how to write the tests, depending on the test harness.
... I propose we could have toby to join at some point. He's responsible for the testing at the W3C.
... I'll check with Toby where he is geographically to see if he can join.

olivier: I'd prefer not to have people join on the phone, as we're all getting together face-to-face. But let's see how it goes.

tmichel: yes, we could dedicate a call with Toby after the f2f if we have any issues.

crogers: The tests that we have from Google as part of webkit, I'd recommend strongly that we look through those tests.
... it's easy to transform the tests to a neutral test harness, but it'll be really interesting to see how the WebKit ones work.

<cwilso> +q to say Web Audio had been mentioned as a topic for a future Test The Web Forward event (4/12-13 in Seattle)

tmichel: we should encourage everyone to have a look through the spec before the meeting.

joe: I have a question about the ordering. I think it might be worth to have the v1 discussion before the triage.
... so that we have a useful filter for how much time to spend on the discussion.

<chris> link to Web Audio tests in WebKit:

<chris> https://svn.webkit.org/repository/webkit/trunk/LayoutTests/webaudio/

chris: thank you!

olivier: that's a good idea.
... cwilso, we're looking at the agenda. We have agreement that there's a focus on testing.

<tmichel> very noisy ..

<tmichel> much better ;-)

olivier: cwilso we're going to add a walk through of the spec to the agenda.
... cwilso, do you think everything that's on the agenda is ok? Would you remove anything?

cwilso: I'd reduce the time spent on the web midi LC discussion, maybe not drop it completely.

olivier: we could also split into two for a period of time if needs be.

Use of EventListener for onaudioprocess

olivier: I'll tweak the agenda on the basis of this discussion.

cwilso: there's a testing event that I've been asked if I want to contribute to.
... I wonder if there's any way this group can help us to test?

<olivier> chrislowis: hope that the f2f will result in documentation on how to test, how to submit etc

olivier: sounds very useful.
... could you summarise the issue crogers?

crogers: I think most people on the list prefer the EventListener target. I think that's how it is implemented at the moment. I have some concerns about people registering multiple event listeners

<olivier> context - https://www.w3.org/Bugs/Public/show_bug.cgi?id=20764

crogers: and if they overwrite data that we could get some glitching.
... I'm happy if we make event node the target and onaudioprocess is the listener.

olivier: do you think that is the way forward for other implementers?

crogers: I think so. I can't speak for Ehsan, but I think that's what he'd like. And we need to tighten up the spec to say that.

<olivier> http://lists.w3.org/Archives/Public/public-audio/2013JanMar/0387.html

crogers: I think Dominic Cooney wrote the best summary of the issue. ^^
... that would mean that we update the spec to say AudioNode inherits from EventTarget.
... and write some tests. That wouldn't be a breaking change to the existing code.

olivier: do you feel comfortable making that change, or would you like someone else to produce a diff and submit that?

crogers: Yes, I can make that change at any time. Ehsan can commit directly to the spec, and I'm happy for him to do that too.

olivier: what's your preference for changes to the spec?

<olivier> example of a patch http://lists.w3.org/Archives/Public/public-audio/2013JanMar/0401.html

crogers: if we've agreed to something and it's uncontroversial, I'd say just go ahead and change. But if it's more nuanced a patch would be better.

<olivier> ACTION: olivier to ask whether we can unlock attachments in bugzilla [recorded in http://www.w3.org/2013/03/14-audio-minutes.html#action01]

<trackbot> Created ACTION-60 - Ask whether we can unlock attachments in bugzilla [on Olivier Thereaux - due 2013-03-21].

<olivier> RESOLUTION: agreement with the suggestion made by Dominic in http://lists.w3.org/Archives/Public/public-audio/2013JanMar/0387.html

<scribe> ACTION: olivier to ask Ehsan to create a patch to the spec for the changes. [recorded in http://www.w3.org/2013/03/14-audio-minutes.html#action02]

<trackbot> Created ACTION-61 - Ask Ehsan to create a patch to the spec for the changes. [on Olivier Thereaux - due 2013-03-21].

olivier: crogers is happy for Ehsan to push changes to the spec. Particularly around the area of exception codes, as he's very knowledgable about this.

crogers: except where he's adding additional exceptions where they don't exist today. We should run those by the group.
... Ehsan is in a great position to design an end-to-end solution about what the exception codes should be.
... in the end most developers will just binary check whether an exception is thrown or not, rather than the exact code.
... so this shouldn't cause any near-term breakages. But they should be consistant in the spec.

Any other business

crogers: I would suggest fixing really easy bugs as we go along during the f2f.
... the low-hanging fruit so to speak.

olivier: that would be great.

crogers: secondly, if there are any particularly contensious issues, perhaps we could put those aside. Get through the uncontroversial ones, and come back to them at the end.

olivier: yes, in the morning after the triage, perhaps we can decide after that.

crogers: sounds good.

olivier: I'll make the changes to the agenda and send it around in the next hour.
... so if there is no other business, let's adjorn for today.

- DRAFT -

Audio Working Group Teleconference

14 Mar 2013

Attendees

Contents

OfflineAudioContext / Memory footprint

Focus of the upcoming f2f

Use of EventListener for onaudioprocess

Any other business

Summary of Action Items

Scribe.perl diagnostic output