Re: Suggestion for minimizing audio glitches

On Tue, Apr 17, 2012 at 10:44 AM, Alistair MacDonald <al@signedon.com>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.
>
> Is that along the lines of what you were thinking Chris?
>

Yes, something like that.  Any of the AudioParam "automation" methods could
be useful:
        void setValueAtTime(in float value, in float time);
        void linearRampToValueAtTime(in float value, in float time);
        void exponentialRampToValueAtTime(in float value, in float time);

        // Exponentially approach the target value with a rate having the
given time constant.
        void setTargetValueAtTime(in float targetValue, in float time, in
float timeConstant);

        // Sets an array of arbitrary parameter values starting at time for
the given duration.
        // The number of values will be scaled to fit into the desired
duration.
        void setValueCurveAtTime(in Float32Array values, in float time, in
float duration);

In your particular example, I am not sure if we would receive a "WebRTC
event for when a stream looses connectivity"
ahead of time enough in advance to get a good fade-out.  But we certainly
have the sharp tools to apply gain envelopes as soon as possible based on
incoming events.  Also, in this particular example, I think I would expect
the WebRTC implementation (ideally) to apply this quick fade-out itself
internally since they're the sub-system supplying the stream.

Chris


>
>
>
>
> On Tue, Apr 17, 2012 at 1:01 PM, Chris Rogers <crogers@google.com> wrote:
>
>>
>>
>> On Tue, Apr 17, 2012 at 9:05 AM, Alistair MacDonald <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.
>>
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Apr 16, 2012 at 5:31 PM, Randell Jesup <randell-ietf@jesup.org>
>>> wrote:
>>> > On 4/16/2012 4:10 PM, Chris Rogers wrote:
>>> >
>>> >
>>> >
>>> > On Sun, Apr 15, 2012 at 12:22 PM, <lemeslep@free.fr> wrote:
>>> >>
>>> >> On the current Web Audio draft, it is mentionned in §15.2 that "Audio
>>> >> glitches are caused by an interruption of the normal continuous audio
>>> >> stream, resulting in loud clicks and pops. It is considered to be a
>>> >> catastrophic failure of a multi-media system and must be avoided."
>>> >> And I can't agree more with this!
>>> >> I'm currently facing those ugly audio glitches in my project. I'm
>>> using
>>> >> Mozilla's Audio Data API at the moment, and I think I know how
>>> browsers
>>> >> could help me to mitigate this problem.
>>> >>
>>> >> The clicks and pops are happening because if the audio buffer is
>>> underrun
>>> >> by the javascript app, the audio card is not feeded anymore, and so
>>> the card
>>> >> output goes straight from the value of the last sample played to 0.
>>> >> What would be needed is, perhaps as an option in the Javascript audio
>>> node
>>> >> (?), to have the browser automatically feed the audio card by
>>> sustaining the
>>> >> last sample the javascript application sent, when the audio buffer is
>>> >> underrun.
>>> >>
>>> >> That would really go a long way towards minimizing this critical
>>> issue.
>>> >
>>> >
>>> > Hi Philippe, I don't think this will help with the glitches.  Using
>>> this
>>> > approach, an under-run will still be quite audible.  And it's not a
>>> good
>>> > idea to send a constant (non-zero) value out to the audio hardware
>>> since
>>> > this represents a "DC offset" and can cause even worse problems.
>>> >
>>> >
>>> > Since underruns may happen no matter what you do (especially if
>>> main-thread
>>> > JS is involved), it's best to minimize the impact of them.  On an
>>> underrun,
>>> > the primary options are:
>>> >
>>> > 1) send 0's (which generally is the audio device default if you don't
>>> feed
>>> > it) - clicks/pops
>>> > 2) repeat last sample - classic lost-packet basic VoIP technique;
>>> works ok
>>> > in most cases; requires blending at start/end to avoid click/pop.
>>> Often
>>> > done at a reduced volume which makes it less noticable.
>>> > 3) decay - take last sample and decay it to silence to avoid click/pop
>>> -
>>> > more useful if you expect continued lack of source.  Can be variant of
>>> #2
>>> > where you progressively decay each missing frame.
>>> > 4) fancier VoIP-style packet loss concealment - better than #2; may
>>> tend to
>>> > be voice-centric
>>> > 5) fancier loss concealment using non-voice centric prediction (waving
>>> hands
>>> > here; I'm sure such things exist for good CD/DVD/etc players).
>>> >
>>> > --
>>> > Randell Jesup
>>> > randell-ietf@jesup.org
>>>
>>>
>>>
>>> --
>>> Alistair MacDonald
>>> SignedOn, Inc - W3C Audio WG
>>> Boston, MA, (707) 701-3730
>>> al@signedon.com - http://signedon.com
>>>
>>
>>
>
>
> --
> Alistair MacDonald
> SignedOn, Inc - W3C Audio WG
> Boston, MA, (707) 701-3730
> al@signedon.com - http://signedon.com
>
>