W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2012

Re: Suggestion for minimizing audio glitches

From: Alistair MacDonald <al@signedon.com>
Date: Tue, 17 Apr 2012 13:44:14 -0400
Message-ID: <CAJX8r2=GYqtyaahQ6Rq67WgiOFooTiwuQFKHJwRQEWyb6wGO_g@mail.gmail.com>
To: Chris Rogers <crogers@google.com>
Cc: Randell Jesup <randell-ietf@jesup.org>, public-audio@w3.org
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?




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
Received on Tuesday, 17 April 2012 17:44:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 17 April 2012 17:44:47 GMT