- From: Cullen Jennings (fluffy) <fluffy@cisco.com>
- Date: Sun, 28 Jul 2013 22:26:53 +0000
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- CC: Tim Panton <thp@westhawk.co.uk>, lonce <lonce.wyse@zwhome.org>, public-webrtc <public-webrtc@w3.org>
I agree with Slivia and Tim, My vague recollection was at one of the early meetings this same suggestion was made and people agreed to add an API (probably constrains) to turn off AGC and another one to indicate it was music or something like that. That was a long time ago and I'm not sure exactly what we need here but my guess is much of the WG will agree with the idea for the JS to say was it wants in a non codec specific way. On Jul 25, 2013, at 2:27 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > I love that idea! There can't be that many different use cases to consider. Do you have a start of a list? Do we separate one-way (streaming) from synchronised two-way (collaboration)? E.g music streaming (even live) has different needs to a distributed live music band. > > Silvia > On 25 Jul 2013 18:19, "tim panton" <thp@westhawk.co.uk> wrote: > When we started discussing the constraints API - this was an issue that came up, > you would be able to mark an audio stream as 'for live music' and the codec params > would be set accordingly. (low latency, high quality, no voice enhancement). > > Even though we have settled on Opus I think it would be a bad plan to expose the > codec specific 'knobs'. Better to allow the developer to express their needs in more > generic terms and have the browser interpret those needs in the context of the codec. > (heck, it might decide to do lin16 at 48khz !) > > T. > > On 14 Jun 2013, at 08:41, lonce <lonce.wyse@zwhome.org> wrote: > >> >> Hello - >> >> I have a couple of questions I have not been able to answer myself after looking over published docs. I am interested in maximum speed and uncompromised quality transmission (for musical purposes), which leads to these questions: >> >> 1) What exactly is the strategy of the "components to conceal packet loss". Is there a strategy specifically for audio packet loss? >> >> 2) Can the audio echo cancellation (AEC), automatic gain control (AGC), and noise reduction, be turned off (not used)? >> >> 3) Can compression by turned off completely (to avoid the algorithmic delay of coding/endcoding)? >> >> 4) If you cannot bypass the compression algorithm, what is the minimum delay one can achieve? It appears to me (from http://www.webrtc.org/reference/architecture and http://en.wikipedia.org/wiki/Opus_%28codec%29 ) that analysis frame sizes down to 2.5ms (CELT layer) and 10ms (SILK layer) are possible. This, in addition to "look ahead" and algorithm delay puts the minimum delay at at least 20 ms, right? >> >> 5) Does one have control over how many analysis frames are sent per packet (could I set it to 1)? >> >> Musicians have been using a system called JackTrip (CCRMA, Stanford University) which suuports uncompressed transmission, and sub-millisecond frames (and packet) size. To recover from UDP losses, it sends redundant streams, and the receiver takes the first packet that arrives with the time stamp it needs next to reconstruct the audio on the receiver. My questions above are all about how close WebRTC can come to achieving the same performance. >> >> Thanks! >> - lonce >
Received on Sunday, 28 July 2013 22:27:25 UTC