Minutes, Audio WG Telcon, 20 Jun 2011

Chair: Alistair MacDonald
Scribe: Chris Lowis
Attendees: Doug_Schepers, Alistair, Ian, quinnirill, chrislo, crogers, 
maboa, kinetik

TOPIC: Administrata
shepazu: reiterating that participants in the group should register.
Alistair: welcoming Mozilla rep and thanking participants who are 
staying up late.
shepazu: mentions http://www.w3.org/2011/audio/wiki/PubStatus 
(Publications and Status)
Alistair: points people to our wiki: http://www.w3.org/2011/audio/
Alistair: chasing up a link to the bug and issue tracker.
Action: Alistair to check on tracker status
Created ACTION-2 - Check on tracker status [on Alistair MacDonald - due 
2011-06-27].
ACTION-2 -- Alistair MacDonald to check on tracker status -- due 
2011-06-27 -- OPEN
http://www.w3.org/2011/audio/track/actions/2

TOPIC: News
<Alistair>
"There should be a pref to completely disable media including disable 
Audio API extension (window.Audio object)" :
<Alistair>
https://bugzilla.mozilla.org/show_bug.cgi?id=665395
Alistair: 1) Mozilla Audio talking about a preference to disable media 
(including audio and video)
Alistair: 2) Robert O'Callahan started work on an implementation.
<Alistair>
http://hg.mozilla.org/users/rocallahan_mozilla.com/media-patches/
shepazu: points out he didn't post that to the group
Alistair: clarifies that it was on Robert's personal page.
Alistair: 3) Group meeting between AudioWG and Real-time communications 
group.
Alistair: 4) Great to see js-mad, an mp3 decoder.
Zakim, who is talking?
<Alistair>
JSMAD MP3 Decoder - http://jsmad.org/play/265379
<Zakim>
chrislo, listening for 10 seconds I heard sound from the following: 
Alistair (15%), chrislo (34%), Ian (35%), quinnirill (19%)
Alistair: 5) Slam-down demo from the Helsinki
<Alistair>
http://traction.untergrund.net/slamdown/
shepazu: I'm using FF-something (on mac), couldn't initialize web gl.
crogers: It's beat-syncronised visuals to a dub step track.

Topic: F2F Meeting during TPAC2011
<Alistair>
http://lists.w3.org/Archives/Public/public-audio/2011AprJun/0088.html
Alistair: link includes dates and so on.
shepazu: thinks it would be good for us to go, if we can.
<shepazu>
http://www.w3.org/2011/11/TPAC/
Alistair: it's on 31 October - 4 November 2011
<shepazu>
Santa Clara, CA USA
Alistair: they're thinking of putting us on the monday or tuesday, as 
the other dates are full.
shepazu: has a preference for the crogers-led spec, but not on technical 
grounds, rather because it is more complete at the moment.
shepazu: we need a face-to-face meeting.
general agreement.
shepazu: expects the RTC people to be at TPAC.
Alistair: do IETF people attend TPAC?
shepazu: in this case they will.
shepazu: there has been some spec-work done on RTC at the what-wg
crogers: there's already some work making it into webkit.
Action: Alistair to chase down a link to this stuff
Created ACTION-3 - Chase down a link to this stuff [on Alistair 
MacDonald - due 2011-06-27].
crogers: there are many use cases for audio that don't involve web-rtc
shepazu: it comes down to the idea of whether we integrate with other 
streams, or whether we work on audio things in isolation.

Topic: RTC methods for scheduling high numbers of 
consecutive/overlapping sounds
<Alistair>
http://lists.w3.org/Archives/Public/public-audio/2011AprJun/0124.html
Alistair: Joe started a thread on the list.
Alistair: asking if people have thoughts on how multiple events can be 
fired off at the same time.
shepazu: notes that generally with DOM-based models the more events that 
are fired the worse the performance
shepazu: so rather than 50 separate elements triggering 50 separate 
sounds, instead re-use an audio "icon"
crogers: that's exactly what my design is.
crogers: we call it an audio buffer, representing PCM audio data.
crogers: and we can do the decoding async from the main JS thread.
crogers: so you can have high-level control of your audio assests, 
short, medium and fairly long samples are possible.
crogers: and they can be reused.
shepazu: it sounds like an audio version of canvas
crogers: it is.
crogers: points out it's a fairly standard architecture used in harware 
synths etc.
Alistair: asking whether the RTC proposal is far enough along for us to 
look if that can be done.
crogers: I'm not sure if it's far enough along yet.
crogers: the api for the audio element is orientated around network 
streaming state and buffering state
crogers: you can use audio elements for streaming audio, but you don't 
have to
crogers: similar to using canvas instead of img tags.
shepazu: so there could be more than one audio element?
crogers: yes, it's already in the spec.
crogers: the audio buffer represents a potential audio asset to be played.
crogers: it could be played 100 times, all overlapping.


TOPIC: Roadmap - Should the Audio WG group take on the larger domain of
general temporal media graphs?
TOPIC: Roadmap - Should the Audio WG group take on the larger domain of 
general temporal media graphs?
Alistair: is it in the scope of this group to deal with streaming at all?
Alistair: at the moment it seems up-in-the-air. Thoughts?
crogers: believes they can be separate APIs with hooks to work with one 
another.
no problem.
shepazu: referring to an on-list comment - should we just stop work on this?
ALL: NO!
shepazu: on the record now.
shepazu: the general feeling seems to be that some of these other areas 
should be more integrated, but not clear how deep deep it needs to go.
crogers: prefers to keep things separate for now.
Alistair: raising the general question about the benefits of bring 
things closer together.
crogers: in discussions at google, feeling that effects on <video> tags 
did not have huge driving use-cases.
crogers: there needs to be a really good API that works well for the 
main use cases
Alistair: those were (from XG), i) making music and ii) gaming
Alistair: while the RTC's main use cases are around communications, 
face-time communications, mobile devices etc.
Alistair: it seems that we share some desires for features, but not so 
many use-cases.
Alistair: which could be tricky if we try to force them together.
crogers: points out that Roger is working on bringing the two together.
maboa: is between the two parties at the moment.
shepazu: that's great, we need people who are open-minded to different 
approaches.

TOPIC: DAW use-cases and the Web Audio spec.
Alistair: if your music application gives you slightly different results 
on every platform, it won't be taking seriously by proffesionals.
crogers: there are two different things that Jussi has brought up.
crogers: all the modes I have included can be defined by precise 
mathematical algorithms.
Alistair: even the 3D positioning stuff
crogers: yes, as it uses Convolution it can be rock-solid if you agree 
on the filters.
crogers: the dynamics compressor is hard to define precisely.
crogers: but having said that, there is no industry-agreed standard for 
compressors.
crogers: so we look to conventions around parameters: attack time, etc.
crogers: the best I can do is say "yes compression is common" and 
provide an implementation, but hard to standardise.
Alistair: that's maybe what the JS node is for - people to provide their 
own algorithms.
Alistair: some people are going to want to do something different.
crogers: exactly, in my proposal there is a way for people to provide 
their own algos.
crogers: but I'm providing a compression algo that I think sounds good.
crogers: good to have a basic compression there for people to use.
crogers: in the spec, everything can be specified to the mathematical 
level, except that compression node.
Alistair: why can't that node be specc'd to that level?
crogers: well, one thing we could do is take my (or another) algo and 
use that as the reference compression algorithm.
crogers: although it's easier to provide reference code than mathematics 
for this kind of node (a bit like shaders in web gl).
crogers: the other question from Jussi was about buffer sizes.
crogers: at the moment in my implementation you can give an explicit 
buffer size.
crogers: there are pros-and-cons to this approach, or one which 
automatically choses buffer sizes.
<smaug>
(not defining something precisely would cause similar problems which did 
lead dropping "Web SQL Database")
crogers: but it needs to be robust enough to prevent glitches.
Alistair: would it be more prudent to give a message to the user saying 
"there's a buffer under-run" and let them deal with it?
crogers: yes, that might be an approach. We need to have further 
discussions about it.
Alistair: let's talk more on the list.
??: (Jussi) agrees we should provide a reference implementation
??: for the compression algorithm.
shepazu: we should regularly move the telecons to make it easier for 
people in turn.
shepazu: let's keep the conversation going on the public list
shepazu: and reconvene in two weeks on the telephone.
... People who have problems joining the WG please contact Alistair or 
Doug (shepazu)

Received on Monday, 20 June 2011 21:26:48 UTC