W3C home > Mailing lists > Public > public-xg-htmlspeech@w3.org > May 2011

[minutes] 12 May 2011 telecon

From: Dan Burnett <dburnett@voxeo.com>
Date: Thu, 12 May 2011 13:40:12 -0400
Message-Id: <6934BDEA-4824-4D78-AD09-D4AF0B31719E@voxeo.com>
To: public-xg-htmlspeech@w3.org
Group,

The minutes from today's call are available at http://www.w3.org/2011/05/12-htmlspeech-minutes.html 
.

For convenience, a text version is embedded below.

Thanks to Dan Druta for taking the minutes!

-- dan


***************************************************************
Attendees

    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

    Chair
           Dan Burnett

    Scribe
           Dan_Druta

Contents

      * [4]Topics
          1. [5]Updated final report draft
          2. [6]Design Decisions with agreements
          3. [7]Issues discussed in the appendix
          4. [8]Audio Codecs
          5. [9]F2F Logistics
      * [10]Summary of Action Items
      _________________________________________________________

    <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:
    [11]http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011May
    /0005.html

      [11] 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>
    [12]http://tools.ietf.org/html/draft-zhu-http-fullduplex-02

      [12] 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>
    [13]http://en.wikipedia.org/wiki/Comparison_of_audio_codecs

      [13] 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.
Received on Thursday, 12 May 2011 17:56:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 12 May 2011 17:56:12 GMT