- 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