W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2011

Re: Mozilla/Cisco API Proposal

From: Cullen Jennings <fluffy@cisco.com>
Date: Mon, 18 Jul 2011 11:13:52 -0700
Cc: Koen Vos <koen.vos@skype.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-Id: <EA594003-1357-4A88-874D-C1BC68799041@cisco.com>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>

As a side note, I hate the label voip / audio. They are not the right labels for what we are talking about. This is all voip and it is all audio. But ignoring the labels...

Let me bring up another use case. E911 calls need to be handled more or less like music instead of speech. For example you turn of voice activity detection, noise suppression and gating for E911 calls. This allows PSAP operator to hear the background noise and decide things like if they need to delay the paramedics knocking on the door until after the police arrive. (where I live average response time of police is far worse than average response time of ambulance so this decision impacts lives). 

I'm arguing the JS app, which is the only thing that knows if this call was being used for that type of purpose, should support a hint along the lines of this. I'm not saying the browsers should have to pay attention to this hint - some will use it, some will ignore it, but I want one hint that all apps can use and not have to write separate code for each browser. 



On Jul 18, 2011, at 7:39 , Stefan Håkansson LK wrote:

> On 2011-07-14 01:54, Koen Vos wrote:
>> Stefan Håkansson wrote:
>>> More and more can be done by analysing the input signal (e.g.
>>> determining if it is speech or music), so perhaps there will be no
>>> need for API support.
>> 
>> That may work in the long term.  But Opus currently has no speech/music detector, and I think it will take a while to build one that is good enough for most use cases.  So for now the API seems the only way we could set the Opus mode.
>> 
>> What are you actually proposing: to hard code the Opus mode, or to quickly invent a reliable speech/music detector?
> I'm proposing that we should not have "audio" or "voip" attributes in
> the API, at least not initially. When the initial version is in use, and
> actual use of it indicate that it would be really beneficial (in certain
> use cases), then we could add it - or perhaps technology catches up
> (maybe a good speech/music detector is available by that time, and it
> can be introduced with no alteration of the API).
> 
> Maybe practical use will indicate that the most important improvements
> of the API is something completely different.
> 
> I have zero knowledge of Opus so I will refrain from commenting on that
> part:)
> 
> Stefan
>> 
>> best,
>> koen.
>> 
>> 
>> Stefan Håkansson wrote:
>> 
>>>>> could help the codec perform at its optimum). And this set could be
>>>>> irrelevant for a new generation of codecs. "audio" vs "voip" is just one
>>>>> example, and it is specific for one codec. I think the general trend also is
>>>> 
>>>> On the contrary, things like AGC and noise suppression are independent
>>>> of _any_ codec (at least they are in the WebRTC stack Google
>>>> open-sourced). Opus implements a few more things internally, but there's
>>>> no reason in principle why those things couldn't be done outside the
>>>> codec as well. The point is that this switch is the difference between,
>>>> "Please actively distort the input I give you to make it sound
>>>> 'better'," vs. "Please preserve the original input as closely as
>>>> possible," and that semantic has little to do with the actual codec.
>>> 
>>> I still think we should not go in this direction - at least not initially. Let's add it later if there is a clear need. More and more can be done by analysing the input>signal (e.g. determining if it is speech or music), so perhaps there will be no need for API support.
>>> 
>>> Stefan
> 
> 


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
Received on Monday, 18 July 2011 18:14:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 18 July 2011 18:14:21 GMT