<burn> trackbot, start telcon

<trackbot> Date: 12 May 2011

<bringert_> I'm having connectivity issues

<bringert_> and it looks like I'm in here twice

<ddahl> bjorn, we can hear you

<bringert> ok, I can't hear anyone else

<bringert> try a different connection

<bringert> trying

<burn> Scribe: Dan_Druta

<burn> ScribeNick: DanD

<burn> Agenda: http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011May/0005.html

Updated final report draft

burn: Made a few changes
... Topic: Design Decisions with agreements

Design Decisions with agreements

Burn: Any new items we agree on?
... No design decisions?
... Any other topics to be discussed later?

Issues discussed in the appendix

Audio Codecs

robert: We don't think we should agree on codec. We should look at a few items: One by bandwidth, ip issues,
... there are trade offs
... fidelity is another issue

burn: We want the ideal codec but there no such thing
... Opus is a combination of codecs and an attempt to provide an industry standard

Milan: RTCWeb is looking at Opus

burn: The issue is which audio codecs is mandatory to support

mbodell: The question is if you can recognize an audio file

Milan: is the synthesizer also part of this?

Bringrt: Three items: 1. Codecs use for remote speech engine

<bringert> 1. codecs used between browser and web app specified recognizer

Milan: 2. Codec use for file speech

<bringert> 2. codecs used between web app and browser for recognition of existing audio

<smaug> there is terrible echo now

<bringert_> 3. codes used between browser and web app specified synthesizer

mbodell: we should allow other codec to be used

Milan: Sounds like requirements

robert: Microsoft uses SIREN owned by Polycom.

burn: Voxeo support all

<bringert> Google uses Speex, FLAC and AMR

Milan: Opus has the notion to cutoff audio and saves bandwidth
... speech has a critical requirement to capture the first part

burn: There are several codecs in Opus
... There was an attempt to merge

Michael: is the issue of support in mobile devices (hardware)
... for the mobile browsing we can rely on hardware and fall back

bringert: The one codec that has must support is Speex
... Caution - there's no container format

burn: another issue is transport (framing)

Milan: isn't an IETF standard

burn: It will require some sort of support for RTP
... How much SIP support will be needed?
... There's disagreement and not everybody want a full SIP stack

bringert: how about OGG?

<bringert> Speex codec in OGG container

<burn> s/disarrangement/disagreement/

burn: It is appropriate not to commit yet and review next week

Milan: It would be useful to know streaming

mbodell: Add a forth item to the list of elements: support for streaming

Milan: can we agree that the architecture should support streaming?

bringert: I'm fine if we support streaming before the engine starts processing

Milan: Recognizer should be able to return results before the end of speech

burn: Recognizer should be able to return final result before the end of speech

bringert: This rules out HTTP

mbodell: You can't get duplex but you can get intermediary responses

Milan: The client can chunk up responses
... Is it a violation if we use web sockets?

<bringert> I'm muted

<smaug> burn: we don't seem to have scribe anymore

burn: We need to be careful not to go in a different direction from RTCWeb

mbodell: different protocol for different use cases
... http works well for certain cases

robert: we don't want to over complicate
... RTC has a different set of requirements

burn: you are right

bringert: We have two choices: we go with http and add RTCweb

robert: or web sockets

bringert: is anyone opposing support for HTTP?
... for streaming
... We support it in Chrome 11
... We want to have http used for other interactions between the user agent and server

mbodell: It's not just audio if we understand correctly
... different apps would use different approaches

burn: we can't predict how it will be used

Milan: there's a continuous response

robert: I'd like to see a proposal before we agree

<bringert> http://tools.ietf.org/html/draft-zhu-http-fullduplex-02

Milan: I agree with a solution that uses HTTP as a basic but not full solution

robert: I would not call Web Sockets HTTP and I'd like to see a proposal

bringert: We should be able to use HTTP

burn: We are saying we are mandating HTTP not eliminating the potential support for other

bringert: the server does not know what's supported on the browser

robert: we need some discovery capability

burn: We believe Web Sockets will not be mandated for support

Milan: I'm not asking for that but a solution for bidirectional support
... if HTTP can do bidirectional we're fine

bringert: there's no reason not support HTTP.

<burn> bringert: would love bidirectional support if we had a good solid candidate for it

Milan: Instead of saying HTTP is required let's list the elements

bringert: We should require HTTP

burn: Agreement - we require http support for all communications and allow for others

mbodell: I'd like to have a solution for bidirectional support but we should not block the spec

burn: other topics around codecs?

mbodell: some audio codecs that support audio and video
... recognize audio from a video+audio stream

bringert: I would suggest we don't send video to reduce bandwidth
... if we don't have strong use cases we should not add it to the spec
... Should we disallow sending video?

burn: no agreements and the best way is not to make any other statements
... add this to the list of topics
... nobody is talking about gesture recognition just audio
... we will get back to this
... Other items related to codecs?

Milan: are there any other candidates:

burn: OPUS. Big but with support for different use cases

<mbodell> http://en.wikipedia.org/wiki/Comparison_of_audio_codecs

F2F Logistics

bringert: no updates
... I will come back with directions from the hotel to the offices
... We sent the directions from the airport
... everybody should have gotten the email

burn: it would still be good if we have some directions from hotel to the Google offices
... one more call before the f2f

bringert: There's a statement about the agreement on the user interface that is not well captured

burn: Yes, I somehow dropped the most important decision -- that it must NOT be possible to customize the part of the user interface that indicates the microphone is open. I will add that in.

This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/codex/codec/
Succeeded: s/disarrangement/disagreement/
FAILED: s/disarrangement/disagreement/
Succeeded: s/We need to revise it/Yes, I somehow dropped the most important decision -- that it must NOT be possible to customize the part of the user interface that indicates the microphone is open.  I will add that in./
Succeeded: s/codex/codecs/g
Succeeded: s/, +44.122.546.aaaa//
Succeeded: s/, +1.425.381.aabb, +1.425.830.aacc//
Succeeded: s/Codex/Codecs/g
Found Scribe: Dan_Druta
Found ScribeNick: DanD
Default Present: Dan_Burnett, Bjorn_Bringert, Milan_Young, Michael_Bodell, Robert_Brown, Dan_Druta, Debbie_Dahl, Charles_Hemphill, Olli_Pettay, Michael_Johnston, Patrick_Ehlen
Present: Dan_Burnett Bjorn_Bringert Milan_Young Michael_Bodell Robert_Brown Dan_Druta Debbie_Dahl Charles_Hemphill Olli_Pettay Michael_Johnston Patrick_Ehlen
Regrets: Marc_Schroeder
Agenda: http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011May/0005.html
Found Date: 12 May 2011
Guessing minutes URL: http://www.w3.org/2011/05/12-htmlspeech-minutes.html
People with action items: