- From: Chris Rogers <crogers@google.com>
- Date: Sat, 21 May 2011 10:37:48 -0700
- To: Antonio José Villena Godoy <_@antoniovillena.es>
- Cc: public-audio@w3.org
- Message-ID: <BANLkTikq+nZyE=63mb8pHd1zv2GU8oRFsQ@mail.gmail.com>
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 On Fri, May 20, 2011 at 9:32 PM, Antonio José Villena Godoy <_@ antoniovillena.es> wrote: > > Hello > > I have created a small program: > > <!DOCTYPE html><html><head> > <script type='text/javascript'> > function buffer(e){ > if( !(++counter % (0x10000/bufferSize)) ){ > nt= new Date().getTime(); > if( counter == (0x20000/bufferSize) ){ > text+= bufferSize + '->' + parseInt(0x10000 * 1000 / (nt - time)) + > '\n'; > e.currentTarget.disconnect(); > bufferSize<<= 1; > if( bufferSize == 32768 ) > alert(text); > else > context= new webkitAudioContext(), > node= context.createJavaScriptNode(bufferSize, 0, 1), > counter= 0x10000/bufferSize - 5, > node.onaudioprocess= buffer, > node.connect(context.destination); > } > time= nt; > } > data1= e.outputBuffer.getChannelData(0); > data2= e.outputBuffer.getChannelData(1); > for (var i = 0; i < bufferSize; i++) > data1[i]= data2[i]= Math.sin(4e3 * (phase++ / context.sampleRate)); > } > bufferSize= 256; > context= new webkitAudioContext(); > text= 'SampleRate->' + context.sampleRate + '\n'; > node= context.createJavaScriptNode(bufferSize, 0, 1); > time= counter= phase= 0; > node.onaudioprocess= buffer; > node.connect(context.destination); > </script></head><body/></html> > > The program sends a sinus wave to the output device at differents buffer > length. When finishes it shows the results: the original sample rate, and > the sample speed for each buffer length (from 256 to 16384). > > A similar test is needed in every application, because optimal buffer > depends on machine performance. So, is possible to add a recommended "buffer > length value" to specification? Something like context.optimalBufferLength > or context.recommendedBufferLength > > Regards > > -- > , _ _ __ ___ _ _ > /_\ _ _| |_ ___ _ _ (_)___ \ \ / (_) | |___ _ _ __ _ > / _ \| ' \ _/ _ \ ' \| / _ \ \ V /| | | / -_) ' \/ _` | > /_/ \_\_||_\__\___/_||_|_\___/ \_/ |_|_|_\___|_||_\__,_| > >
Received on Saturday, 21 May 2011 17:38:13 UTC