- From: Joe Meadows <jam@jamspace.com>
- Date: Mon, 10 Mar 2014 09:34:41 -0700
- To: robert@ocallahan.org
- CC: "public-audio@w3.org" <public-audio@w3.org>
- Message-ID: <531DE9A1.9090007@jamspace.com>
I did experiment with that but I couldn't get it to work reliably. I tested with Firefox and found that the audio element still buffered, so there was a significant delay before playback started, and I was getting dropouts on occasion. It's possible that I could have tuned it just right for this particular browser but I gave up on this approach because it I didn't feel like it was going to produce reliable, consistent results among various clients. Thanks, Joe On 03/10/2014 03:35 AM, Robert O'Callahan wrote: > On Fri, Mar 7, 2014 at 9:18 AM, Joe Meadows <jam@jamspace.com > <mailto:jam@jamspace.com>> wrote: > > *Example application* > I have a client/server audio synthesizer project. The server > generates a stream of Ogg/Vorbis audio that is rendered by the > client (browser) using an HTML audio tag. The client can change > various parameters (e.g. pitch, gain, pan, etc) and the server > will immediately alter the output stream accordingly. > > This arrangement if very nice because it requires nothing special > on the client side. However, in the browsers that I've tried the > audio element buffers very aggressively, literally several > minute's worth of data. So when the user tweaks a setting it will > not be heard in the browser for a long time, even though the > server immediately reflected the change. > > > Can you modify the server so that it doesn't deliver data faster than > real time? > > Rob > -- > Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny > eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha > iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e > tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt > hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * > *
Received on Monday, 10 March 2014 16:35:13 UTC