W3C Audio WG Teleconference -- 21 Nov 2013

olivier: where were you? There's a real party going on here!

<kawai_> I am on now.

Review of action items

<olivier> http://www.w3.org/2011/audio/track/agenda

<scribe> scribenick: chrislowis

olivier: Action 80 was on cwilso, to remove the example applications

cwilso: I have not done that yet

olivier: need another couple of weeks?

<olivier> action-80 due in 2 weeks

<trackbot> Set action-80 Remove webaudio section on example applications, photos from section on convolution, and salvage anything valuable due date to 2013-12-05.

cwilso: yes please.

olivier: Action 83 was on shepazu to start a space for documentation.
... any progress?

<olivier> action-83 due in 2 weeks

<trackbot> Set action-83 Get started with a space on wpd to survey docs on good practice for webaudio due date to 2013-12-05.

shepazu: no, but I'm starting it today.

olivier: Matt Paradis is waiting on that here at the BBC to help out.

shepazu: great.

TPAC MIDI session report

<olivier> http://www.w3.org/wiki/TPAC2013/session-musicalinstruments

olivier: we have a new participant on the call today.
... Ryoya is on the call.
... he convened a session on MIDI and the activities, especially in Japan, where there is a growing community of developers playing with the Web MIDI and other APIs.
... there's been some interesting hack-a-thons that have yielded interesting results
... mixing and playing with Web MIDI, Web Audio and, for example, getUserMedia.

<olivier> http://github.com/ryoyakawai/WebMIDIAPIWrapper

olivier: Ryoya shared with us (at TPAC in Shenzen) some other ideas, such as this wrapper around the Web MIDI api which allows a higher level access to the API.
... cwilso was also at the session remotely.

<kawai_> I have uploaded slide > http://www.slideshare.net/ryoyakawai/breakouttpac-2013

olivier: any questions from the group on this?

kawai: thank you olivier.

olivier: and thanks to kawai from joining at a nasty time difference!
... we had a discussion at the last meeting about other visible data races.
... not the one on audio buffer which has been resolved.

<olivier> https://github.com/WebAudio/web-audio-api/issues/268

olivier: there was an action on cwilso and rtoyg to come up with a proposal.

cwilso: this was splitting out the issue from #254, rtoyg and I haven't had chance yet to sit down and come up with a proposal for how to deal with this.

olivier: do you mind if I assign the issue to you?

cwilso: no that's fine.

olivier: I don't think padenot is on the call today, so we won't look into that today.

Dezippering

("that" being agendum 2)

<olivier> https://github.com/WebAudio/web-audio-api/issues/48

<olivier> https://github.com/WebAudio/web-audio-api/issues/76

<olivier> http://lists.w3.org/Archives/Public/public-audio/2013OctDec/thread.html#msg242

<olivier> chrislowis: wanted to explain and bring up discussion

<olivier> ... then discussion on whether and when to apply it

<olivier> ... it adds a bit of weight to the spec, because it needs to be clearly defined

<olivier> ... question is whether it is worth adding this convenience

<olivier> olivier: is chrome implementing it for most parameters

<olivier> chrislowis: yes, from what I could see in code

<olivier> olivier: how about putting dezippering on roadmap for v2?

<olivier> rtoyg_: would prefer to keep it because already in chrome

olivier: we have joe

joe: I want to understand what it means to move it to v2?
... remove it from the implementations? Or leave it vague in the spec and clarify in v2.

olivier: we are looking into the possibility of having mathematical oscillators
... does that help?

chrislowis: no, I think that's more to do with avoiding aliasing at high freuencies

cwilso: with respect to dezippering, the goal was to reduce audible artifacts
... to make it sound good by default
... and the only place where there are some slight issues are with the frequency of oscillaotrs
... and it would probably happen with playback rate.
... the sub-question of should we define it differently for different things?
... we should go through and see if we can minimise the places where it could cause issues
... and we need to be upfront about where it happens.

olivier: and this is about the behaviour of setting the 'dot' value does.

cwilso: yes, and preferably in terms of the other methods setValueAtTime etc.
... I don't think we need to talk about specific values etc.

joe: the dezippering issue isn't just about weight or complexity of the spec.
... it's also a philosophical question about whether the API should apply a "spin" on what the developer is asking of it.
... I think there's a level of discomfort about the API providing an "interpretation" of a raw value change, instead of setting something directly.
... having said that, it's really hard to achieve effects using the setter anyway, as there's no way to schedule things - for rapid gain changes for example you'd need to use the setTargetAtTime type methods with timing data.

olivier: I think one part of the issue is about defining the exact behaviour of smoothing, since it is already in implementations.
... the second part is whether the implementations should apply that value or not.
... it is, as Joe explained, somewhat of a philosophical issue as well as a technical one.

cwilso: I think the former issue, defining the exact behaviour, is trivial in comparison to deciding whether implementations should do this or not.

chrislowis: for what it's worth I think keeping the setter having the smoothing and applying it across the board, defined in terms of exponentialValueAtTime or something is a nice compromise.

cwilso: whatever we decide, no one is prevented from doing certain things as we have a few different ways of achieving things.
... I think we do get questions today about the unexpected behaviour

olivier: I'm hearing that noone is really against the status quo that has been set by the current implementation.

cwilso: I wouldn't object to that as long as we are detailing it in the spec.
... I'd like to hear some input from mozilla.

olivier: chrislowis can you summarise for the list?

chrislowis: yes.

<olivier> ACTION: chrislowis to followup on ml about dezippering, summarize discussion and rough consensus [recorded in http://www.w3.org/2013/11/21-audio-minutes.html#action01]

<trackbot> Created ACTION-84 - Followup on ml about dezippering, summarize discussion and rough consensus [on Chris Lowis - due 2013-11-28].

<olivier> ACTION: olivier to issue CFC on dezippering around current Chrome/Blink behaviour [recorded in http://www.w3.org/2013/11/21-audio-minutes.html#action02]

<trackbot> Created ACTION-85 - Issue cfc on dezippering around current chrome/blink behaviour [on Olivier Thereaux - due 2013-11-28].

Web Array Math API CG

olivier: at TPAC last week, I had discussions with a few people including Lars Erik at Opera
... about the math API that Marcus had proposed.
... and that we could develop this within a community group

<olivier> http://www.w3.org/community/webarraymath/

olivier: so this would become some kind of DSP api has been previous discussed.

gmandyam: how do APIs such as this work when they are defined in terms of external hardware? Are they discussed in terms of specific hardware, or is it more like the Web Audio API where we fall back to a "software solution" when hardware support isn't there?

olivier: I guess it would be something like the latter.

gmandyam: when the DSP API came out, I did get some evaluation from my parent company (Qualcomm), and they didn't think it was a very good match for the kind of thing we offer. Just a point that there is good intentions behind these APIs, but that it isn't always possible to implement.

MediaElementAudioSource test

<olivier> https://github.com/w3c/web-platform-tests/pull/396

<olivier> chrislowis: contribution to webplatform tests in our directory

<olivier> ... amitay is trying to use MediaElementAudioSource

<olivier> ... not sure how to use with OfflineAudioContext

<olivier> ... require review of the test

<olivier> ... also wanted a discussion about how to tighten the spec

<Zakim> cwilso, you wanted to suggest MEAS and MSAS) should be disabled in offline.

<olivier> cwilso: not sure how you would reconcile mediaElement/mediastreamAudioSource in offline context

<olivier> ... they tend to be real time

<olivier> ... so should just not be there

<olivier> chrislowis: perhaps something to raise an issue about

<olivier> ... or a pull request on which nodes are available in offlineaudiocontext

<olivier> olivier: should we keep it as negative test

<olivier> chrislowis: keep it for audiocontext, and add a negative one for offline audiocontext

<olivier> RESOLUTION: MediaElementAudioSource and MediaStreamAudioSource should not be present in OfflineAudioContext

<olivier> ACTION: document the case of MediaElementAudioSource and MediaStreamAudioSource nodes in offlineaudiocontext on github [recorded in http://www.w3.org/2013/11/21-audio-minutes.html#action03]

<trackbot> Error finding 'document'. You can review and register nicknames at <http://www.w3.org/2011/audio/track/users>.

<olivier> ACTION: chrislowis to document the case of MediaElementAudioSource and MediaStreamAudioSource nodes in offlineaudiocontext on github [recorded in http://www.w3.org/2013/11/21-audio-minutes.html#action04]

<trackbot> Created ACTION-86 - Document the case of mediaelementaudiosource and mediastreamaudiosource nodes in offlineaudiocontext on github [on Chris Lowis - due 2013-11-28].

olivier: AOB?

next meetings

olivier: on the 5th and the 19th December.
... I'm not hearing a lot of regrets for those dates, so we'll go with those tentativly.
... before we close, following the discussion at the last teleconference we are going to publish a new draft of the Web MIDI api, probably next week.
... thank you all.
... no problem!

- DRAFT -

W3C Audio WG Teleconference

21 Nov 2013

Attendees

Contents