Re: API for streaming encoded audio

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 *
> *