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