- From: Antonio José Villena Godoy <_@antoniovillena.es>
- Date: Sun, 22 May 2011 17:13:47 +0200
- To: Chris Rogers <crogers@google.com>
- CC: public-audio@w3.org
Hello Chris I put these alternatives: 1. Like now, programmer can choose between 256..16384 size buffers. 2. The same, but with a suggested buffer size (depends on machine) from the browser. 3. Like Flash, with an internal dynamical buffer and a fixed & small callback buffer (256 bytes for example). 4. A mix between 2 & 3: 4a. The programmer writes 7 differents onaudioprocess routines, one for each buffer length, and the browser dynamically call the optimal one. 4b. The programmer writes only a onaudioprocess routine, but with the buffer length in a parameter. Regards El 21/05/11 19:37, Chris Rogers escribió: > Hi Antonio, > > You're right that the smallest working buffer size can vary depending on > the type and speed of the machine, the type of browser, etc. We have > talked on this list about removing the buffer size argument from > createJavaScriptNode() and instead letting the system choose the optimal > buffer size automatically. Optionally, we could provide a hint as to > how tolerant we would be of glitching which could influence this choice. > I believe Flash has a different approach where they have an additional > internal buffering which can dynamically increase even while the > callback buffer size remains fixed and could be small. The disadvantage > to that approach is that the latency becomes unpredictable and can > increase over time, for example during gameplay. The advantage is that > it's dynamically able to adapt to fix the glitching as it comes up and > also let's the user pick a relatively small callback buffer size if > that's convenient for them. > > It's clear we need something better than the current approach of simply > picking a buffer size and hoping for the best. I'm interested in > hearing from people who have experience using the Flash API and their > thoughts on the dynamically increasing internal buffering (with latency > implications)... > > Cheers, > Chris -- , _ _ __ ___ _ _ /_\ _ _| |_ ___ _ _ (_)___ \ \ / (_) | |___ _ _ __ _ / _ \| ' \ _/ _ \ ' \| / _ \ \ V /| | | / -_) ' \/ _` | /_/ \_\_||_\__\___/_||_|_\___/ \_/ |_|_|_\___|_||_\__,_|
Received on Sunday, 22 May 2011 15:14:16 UTC