Great! As I've said, I'm definitely bias towards this approach. As Bjorn hinted AJAX APIs could be developed with all sorts of interesting features that will never make it down into the browser, e.g. pronunciation assessment, speech therapy, all those lie-detector apps for your phone :-). Still, I think that we're missing the biggest pro:<div>
<div><br></div><div>- Pro: Speech recognition technology is data-driven. Improvements in the underlying technology are far more likely to occur with a network driven approach. </div>
<div><br></div><div>To be fair, with that, you have to add a con:</div><div><br></div><div>- Con: Less privacy.<br><br></div><div>-Ian<br><br><div class="gmail_quote">On Tue, Dec 15, 2009 at 3:37 PM, Ian Hickson <span dir="ltr"><<a href="mailto:ian@hixie.ch" target="_blank">ian@hixie.ch</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>On Tue, 15 Dec 2009, Bjorn Bringert wrote:<br>
><br>
> - A general microphone API + streaming API + audio tag<br>
> - Pro: Useful for non-speech recognition / synthesis applications.<br>
> E.g. audio chat, sound recording.<br>
> - Pro: Allows JavaScript libraries for third-party network speech services.<br>
> E.g. an AJAX API for Google's speech services. Web app developers<br>
> that don't have their own speech servers could use that.<br>
> - Pro: Consistent recognition / synthesis user experience across<br>
> user agents in the same web app.<br>
> - Con: No support for on-device recognition / synthesis, only<br>
> network services.<br>
> - Con: Varying recognition / synthesis user experience across<br>
> different web apps in a single user agent.<br>
> - Con: Possibly higher overhead because the audio data needs to<br>
> pass through JavaScript.<br>
> - Con: Requires dealing with audio encodings, endpointing, buffer<br>
> sizes etc in the microphone API.<br>
<br>
</div>FWIW I've started looking at this kind of thing in general (for audio and<br>
video -- see <device> in the spec for the first draft ideas), since it'll<br>
be required for other things as well. However, that shouldn't be taken as<br>
a sign that the other approach shouldn't also be examined.<br>
<font color="#888888"><br>
--<br>
Ian Hickson U+1047E )\._.,--....,'``. fL<br>
<a href="http://ln.hixie.ch/" target="_blank">http://ln.hixie.ch/</a> U+263A /, _.. \ _\ ;`._ ,.<br>
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'<br>
</font></blockquote></div><br></div></div>