<ehsan> chrislowis: why did you drop Testing?

<chrislowis> ehsan: sorry, got it all in the wrong order :)

<ehsan> cool!

<chrislowis> gmandyam: Hello!

<chrislowis> ScribeNick: gmandyam

<shepazu> trackbot, start telcon

<trackbot> Meeting: Audio Working Group Teleconference

<trackbot> Date: 23 May 2013

chrislowis: We'll start with Offline Audio Context

offlineAudioContext

ehasan: Last time I think we discussed most of the big issues. There was 1 big issue remaining: whether we should be able to change the I/F to allow startRendering to be called multiple times.

ehsan: crogers felt that such a change would break existing web content.

crogers: There are people who are using this feature, but I have found a solution that would allow calling of startRendering multiple times.
... My proposal is that startRendering can be invoked multiple times, but the dev. has to wait for the oncomplete event handler to be invoked before calling again.

ehsan: But you would still have to pass the entire processing length to the constructor?

corgers: No. The length would refer to the length of processing time for each incremental processing chunk.

Previous note correction: 'corgers' is 'crogers'

ehsan: That is mostly fine. There is one remaining problem: some people could want to pass in different lengths depending on different circumstances.

crogers: startRendering could take in a length argument that overrides the constructor argument in that case.
... I don't think this is going to be a big issue in practice.

ehsan: I feel this API is still constructed weirdly. Length should not be in the constructor.

crogers: I have seen bugs filed to Chrome on OfflineAudioContext. People are using it.
... It has been in Chrome since last November/early December. I am hesitant to significantly modify the API at this point.

ehsan: (To crogers) Please propose this idea to the list. I am fine with this proposal.

<chrislowis> ACTION: crogers to propose idea for OfflineAudioContext to list [recorded in http://www.w3.org/2013/05/23-audio-minutes.html#action01]

<trackbot> Created ACTION-62 - Propose idea for OfflineAudioContext to list [on Chris Rogers - due 2013-05-30].

ehsan: The other remaining issue: using OfflineAudioContext to deal with real-time nodes outside of the audio graph (e.g. MediaElement as source - how do we deal with this?
... crogers suggested during the last call that such nodes be prohibited from OfflineAudioContext.

crogers: I don't see any use for such a feature either. It is overly complex to spec out such a requirement.

ehsan: No backwards-compatibility requirement?

crogers: Current Chrome/Safari implementations will not work with such nodes, so there is no backwards-compatibility issues with posing this requirement.

chrislowis: How do we show this restriction in the spec?

crogers: Don't know how to address this in the IDL. Maybe a comment on when an exception is thrown.

ehsan: Maybe allow for a return type to be null with UA requirements upon encountering real-time nodes for OfflineAudioContext. No exception is required.

chrislowis: Please propose this as well to the list.

ehsan: I'd prefer this be part of crogers' action item so that all the OfflineAudioContext changes can be viewed together.
... I think these two changes should address all of Mozilla's concerns

<chrislowis> ACTION: ehsan will reply to Chris's proposed changes to OfflineAudioContext with updated WebIDL. [recorded in http://www.w3.org/2013/05/23-audio-minutes.html#action02]

<trackbot> Created ACTION-63 - Will reply to Chris's proposed changes to OfflineAudioContext with updated WebIDL. [on Ehsan Akhgari - due 2013-05-30].

<marc> shepazu: thanks

Testing

chrislowis: Let us continue on the agenda with the testing topic.

ehsan: I meant to pose something on the mailing list re: testing.
... I'd like to share our experiences we have gained using OfflineAudioContext and ScriptProcessorNode for testing.

We use this methodology to compare observed results with expected results.

crogers: Not all the tests we use test only a specific node.

ehsan: Each test have two functions: createGraph and createExpectedBuffers. So we can test entire graphs.
... Our tests can return multiple nodes if necessary, but we haven't found a reason to inspect multiple nodes yet.
... This is to keep the tests simple.

<marc> shepazu: thanks, and in case anyone else is curious, I'm Marc Novakowski from Pandora

crogers: In most of our tests, we don't examine the nodes. We compare against theoretical values or expected buffer values.
... It would be helpful if we did a comparison between the Webkit/Blink and Mozilla tests.

ehsan: I have been examining some tests in the Webkit tree, but this is an ongoing exercise. I don't expect any fundamental incompatibilities.
... The createExpectedBuffer function can be used to generate a buffer independent of the input graph.

crogers: We examine a subset of the samples to determine correctness. Our convolution test is relatively complex. Our square,square convolution test for instance doesn't yield a perfect triangle.
... But we allow passing of the test based on an error tolerance.

chrislowis: How much of the complexity should we capture in the testing framework that accompanies the spec? - to crogers

crogers: I think tests like the convolution test have allowed us to verify different FFT back-ends. The observed SNR is very high (on the order of 100 dB or more).

ehsan: I think both types of tests should be allowed: buffer comparison where a boolean is returned, and SNR tests.

chrislowis: These approaches to testing methodology should be circulated to the mailing list.

crogers: We should create a general sharable test framework. We've written around 80 tests in Webkit, and I think the form of the tests are already in a near-neutral format.
... We have some dependencies on the Webkit test harness, but not many.

chrislowis: I didn't have to make to many changes when I ported the Webkit tests.

ehsan: Mozilla intends to use the Webkit tests as soon as possible.

<chrislowis> Example ported test from WebKit: https://github.com/WebAudio/web-platform-tests/blob/master/webaudio/the-audio-api/the-gainnode-interface/gain-node-webkit.html

<chrislowis> Link: http://lists.w3.org/Archives/Public/public-html-testsuite/2013May/0003.html

ehsan: One more item to raise on testing: how much of the spec will we actually test?

chrislowis: We don't close a bugzilla bug on a spec feature until we update the test.

gmandyam: We are currently leveraging the Webkit test harness for internal testing. I don't believe the W3C test suite needs to be as extensive. It can serve as a guideline for 3rd parties who want to develop their own tests.

shepazu: I don't think anyone is saying that we just rubber stamp Webkit tests as the W3C official test methodology.

ehsan: There are issues with leveraging the Webkit tests as it to form the basis for the W3C test suite. For one, the Webkit implementation is not currently spec compliant.

crogers: We could use the Webkit tests as a starting point, but I know there are Webkit-based browser vendors who would like to transition to W3C-sanctioned tests.

ehsan: I think there is value to coming up with the detailed feature test as the official W3C test suite.

shepazu: Traditionally W3C test suites have not been used for conformance or interop. It is testing the implementability of a specification. We are shifting to more aspirational testing, particularly for interop.
... W3C will never provide a 'complete' test suite, so implementers will still be responsible for developing some tests on their own. In order to move the spec forward, we should have a good representative set of tests.

chrislowis: I agree. We need to find a sweet-spot to where the tests are useful, but are not so comprehensive that it holds up the spec work.

ehsan: I agree.

marc (from Pandora): The items being dealt in this group are lower-level than we are used to, so we don't have any contributions at this point.

chrislowis: We also have a developers mailing list.

marc: We are looking into details of the API so that we could become users of the API.

<marc> Seth Levy from Pandora

Seth (from Pandora): We are interested in the API as developers, not browser vendors.

<chrislowis> Developers list: http://lists.w3.org/Archives/Public/public-audio-dev/

<chrislowis> shepazu: http://en.wikipedia.org/wiki/Additive_synthesis

<chrislowis> shepazu: http://en.wikipedia.org/wiki/Subtractive_synthesis

<chrislowis> shepazu: http://webaudio.prototyping.bbc.co.uk/

<mdjp> marcosc - as chrislowis has pointed out there is a very simple solution to the problem, please see new mail.

<mdjp> and thanks chrislowis!

<shepazu> trackbot, end telcon

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: gmandyam
Inferring Scribes: gmandyam
Default Present: chrislowis, ehsan, +1.604.628.aaaa, gmandyam, gmandyam\, Doug_Schepers, crogers, +1.954.336.aabb
Present: chrislowis ehsan +1.604.628.aaaa gmandyam gmandyam\ Doug_Schepers crogers +1.954.336.aabb
Found Date: 23 May 2013
Guessing minutes URL: http://www.w3.org/2013/05/23-audio-minutes.html
People with action items: crogers ehsan reply will

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.