Re: Suggestion for minimizing audio glitches

On 4/17/2012 1:44 PM, Alistair MacDonald wrote:
> OK, that's great.
>
> Assuming there is be a WebRTC event for when a stream looses
> connectivity, I guess you would just setValueCurveAtTime() to the gain.
> Then ramp up quickly when the stream re-connects.

Generally there is no notification; WebRTC runs over UDP.  There are a 
few cases where we do know we've lost connectivity temporarily (IP 
change, etc), plus call-end.

WebRTC's internal audio processing will generally conceal lost audio 
packets (which would likely include IP change), so really the only thing 
left would be end-of-call or close-tab.

> Is that along the lines of what you were thinking Chris?
>
>
>
>
> On Tue, Apr 17, 2012 at 1:01 PM, Chris Rogers <crogers@google.com
> <mailto:crogers@google.com>> wrote:
>
>
>
>     On Tue, Apr 17, 2012 at 9:05 AM, Alistair MacDonald <al@signedon.com
>     <mailto:al@signedon.com>> wrote:
>
>         Randell's 1-5 suggestions are very interesting.
>
>         I would think putting this behavior on the destination node
>         might be odd. But I wonder if adding this kind of behavior to a
>         something like the gain node might be useful?
>
>         For example: if I wanted to combine Video-Chat with a DAW (UC-1
>         & UC3), then the following issues would be in play...
>
>         1) If a VOIP stream stops suddenly, the user might think there
>         was a pop/click in their audio track. Adding a tail/decay would
>         be a solution. (Randell's Option 3)
>         2) Being a DAW, we would need as much CPU as possible. So
>         avoiding the tail calculation in JavaScript would be ideal.
>
>
>     We should be able to do this today with a fade-out using an
>     AudioGainNode.


-- 
Randell Jesup
randell-ietf@jesup.org

Received on Tuesday, 17 April 2012 18:28:11 UTC