Minutes from the todays Telcon

Apologies to the group, I seem to have screwed up the automation of the
minutes today. I have copied the minutes manually in this email so we have a
record of what was discussed.


*Minutes from The AudioXG Meeting, **September 20th 2010*


*Zakim: agendum 1. "VOIP"*


Al: We discussed VOIP briefly by email, are there any further thoughts on
the subject?

Chris Rogers: I pinged somebody on our Google Talk team. He said the one
overlap was spatialized panning for the voices in a conference call
situation.

Doug: I can try and find out about the device tag and report back to you on
what the status is. I think it will become increasingly important to us.

Doug: I think "device" is in the WHATWG draft but not in the W3C draft,
hopefully this will change.

Chris Rogers: I think that however the device tag turns out, I think there
will be an obvious, logical way to connect it into the Web Audio API.

Doug: recent email:
http://lists.w3.org/Archives/Public/public-html/2010Jul/0145.html

Doug: http://www.w3.org/TR/2010/WD-html-media-capture-20100720/

Doug: http://dev.w3.org/html5/html-device/

David: on the Google side, there is iChat and Face-time on the iPhones. I
think you can have high quality video conferencing on the iPhone and we
could see what their thoughts would be on the issue.

Doug: I see that the HTML device API has been worked on recently:
http://dev.w3.org/html5/html-device/

Doug: I am concern that if device does not gain momentum, we are likely to
see fragmentation because I think this is something that people really want.
There will probably be increasing demand for this from device manufacturers.
If we don't meet this need we may have a generation of fragmented
implementations.

Chris Rogers: Doug are you thinking in terms of teleconferencing or are you
thinking of musical input as well?

Doug: I had a discussion with someone else about an extensible event
mechanism to work with various devices, even if the OS does not know much
about the device.

Al: I think the device tag would also be important for accessibility.

Doug: Exposing the microphone in a way that people are comfortable with is
important in terms of security. There has to be some sort of handshake. Even
if it's a "yes I agree this webpage can use the device from now on" approval
from the user.

Chis Rogers: I would separate it into 2 use cases. 1) Using the microphone
to sing or speak into, and 2) record guitars or keyboards in a web
application.

Doug: Could that be satisfied by just opening up the mic?

Chris Rogers: Yes, as long as you have the interface and can read the data.

Doug: I think people would quickly run up against barriers. I think that
just opening up the mic may not be enough. For example my phone might run
DSP on my voice to amplify the right vocal frequencies.

Al: I guess what we are talking about is being able to read from the sound
card's input device rather than "just" the microphone so you can select
which input is being used.

Rikrd: It looks like this is covered in the device spec. They also cover
putting the stream into the video or audio tag. Any DSP could be done by
nodes in the audio API.

Chris Rogers: That fits with what I am proposing in the Web Audio API.

Rikrd: If you want really short latency, you might want to be able to change
the size of data slices coming in. The device should be able to tell you
"this is the minimum I can give you".

Chris Rogers: We already have that for the output side of things. Often
times these drivers work by writing the output buffer the same size as the
buffer coming from the input device.

Rikrd: Yes, so I think its important to be able to query the buffer
capabilities of devices.

Chris Rogers: You have to choose a buffer size that is large enough, and
take JavaScript performance into account too.

 *
*

* Zakim agendum 2. "Syncing media, sample-offset"*


Al: Do we have everything we need do synchronize separate media elements
such as video and audio?

Chris Rogers: I think it would be good to have a timestamp on media
elements. We do not have this already. We could start discussions about what
this API might look like.

Chris Rogers: This is the same type of problem that has been solved in
Quicktime for example, using operating system level calls.

Chris Rogers: You want to know what time in the movie you are at, and what
time it is on the master-clock. You can then make a comparison between media
elements and do your processing accordingly.

Doug: Here's a new effort on Web Timing:
http://dev.w3.org/2006/webapi/WebTiming/

Doug: http://www.w3.org/2010/webperf/

Doug: There is a new web performance working group for Web Timing, which may
be relavent: http://dev.w3.org/2006/webapi/WebTiming/

Doug: I wonder if we should be talking to these people about what we are
doing and perhaps aking for a couple of additions for syncronising media?

Doug: http://www.w3.org/TR/progress-events/

Chris Rogers: I can take a look at this and see what I can find out.

Doug: We could also look at Progress events:
http://www.w3.org/TR/progress-events/ There may some correlation here too.

[end of meeting]