Interested in making your Chrome Extension (or packaged app) talk using synthesized speech? Chrome now includes a Text-to-Speech (TTS) API that’s simple to use, powerful, and flexible for users.

Let’s start with the "simple to use" part. A few clever apps and extensions figured out how to talk before this API was available – typically by sending text to a remote server that returns an MP3 file that can be played using HTML5 audio. With the new API, you just need to add "tts" to your permissions and then write:

chrome.tts.speak('Hello, world!');

It’s also very easy to change the rate, pitch, and volume. Here’s an example that speaks more slowly:

chrome.tts.speak('Can you understand me now?', {rate: 0.6});

How about powerful? To get even fancier and synchronize speech with your application, you can register to receive callbacks when the speech starts and finishes. When a TTS engine supports it, you can get callbacks for individual words too. You can also get a list of possible voices and ask for a particular voice – more on this below. All the details can be found in the TTS API docs, and we provide complete example code on the samples page.

In fact, the API is powerful enough that ChromeVox, the Chrome OS screen reader for visually impaired users, is built using this API.

Here are three examples you can try now:

    TTS Demo (app)
    Talking Alarm Clock (extension)
    SpeakIt (extension)

Finally, let's talk about flexibility for users. One of the most important things we wanted to do with this API was to make sure that users have a great selection of voices to choose from. So we've opened that up to developers, too.

The TTS Engine API enables you to implement a speech engine as an extension for Chrome. Essentially, you provide some information about your voice in the extension manifest and then register a JavaScript function that gets called when the client calls chrome.tts.speak. Your extension then takes care of synthesizing and outputting the speech – using any web technology you like, including HTML5 Audio, the new Web Audio API, or Native Client.

Here are two voices implemented using the TTS Engine API that you can install now:

    Lois TTS - US English
    Flite SLT Female TTS - US English

These voices both use Native Client to synthesize speech. The experience is very easy for end users: just click and install one of those voices, and immediately any talking app or extension has the ability to speak using that voice.

If a user doesn't have any voices installed, Chrome automatically speaks using the native speech capabilities of your Windows or Mac operating system, if possible. Chrome OS comes with a built-in speech engine, too. For now, there's unfortunately no default voice support on Linux – but TTS is fully supported once users first install a voice from the Chrome Web Store.

Now it's your turn: add speech capability to your app or extension today! We can't wait to hear what you come up with, and if you talk about it, please add the hashtag #chrometts so we can join the conversation. If you have any feedback, direct it to the Chromium-extensions group.

Posted by Dominic Mazzoni, Software Engineer

Editor's note: The Chromium WebGL team worked closely with the Maps team to help make MapsGL a reality. We invited a member of the Maps team to talk about their experience with MapsGL in the hope that it would help inform others who are interested in deploying a large scale WebGL app.

At this point it's almost hard to remember, but when Google Maps was first released in 2005, it was one of the first web applications to demonstrate what was possible with AJAX and the web platform. This project was a challenge technically but we’d like to think that it helped to fire the imaginations of web developers around the world.

Today, the Maps team is launching a beta of a brand new experience we call MapsGL. MapsGL is one of the first large scale applications to be built on top of WebGL. MapsGL makes use of 3D rendering and hardware graphics acceleration to provide an experience that is seamless, smooth, and runs directly in the browser.

Technically, MapsGL brings significant changes to how map and image tiles are rendered on the client and server. Rather than loading pre-rendered image tiles from servers, vector data for the map is sent to the browser and rendered on the fly using WebGL. This generally means that less data needs to be sent to the browser, but also that every aspect of the map needs to be rendered on the order of ~20ms per frame in order to achieve a reasonable frame rate. Imagery transitions in Maps are also enhanced by loading 3D metadata along with image tiles, allowing Maps to provide rich 3D transitions between different levels and angles of imagery.

While developing MapsGL, we found that WebGL draws from both native and web app backgrounds. For those used to working on web applications, WebGL adds a lot of functionality, but also increases the complexity of what you need to build and test. Even though WebGL is cross platform, performance varies dramatically across graphics hardware and operating systems - and what improves performance on one may hurt performance elsewhere - so testing across a wide array of setups is critical.

We also found that performance dependent Javascript and WebGL optimizations were needed in order for MapsGL to run properly on slower hardware. For example, there are a number of users with graphics cards that can't currently run WebGL content. In these cases, we don’t give the user the ability to opt-in and they can continue with the current Maps experience. Other graphics cards have somewhat poor performance for some key operations, which we measure with a small benchmark when the user first opts-in. In these cases, MapsGL falls back on a hybrid approach where we use pre-rendered raster tiles for the background of the map and only dynamically render labels on top of these.

We hope that MapsGL makes you excited to use WebGL in your own app. WebGL enables 3D graphics and immersive experiences in the browser that were formerly impossible. As WebGL becomes more robust and graphics card drivers improve, we can't wait to see what web developers will create with it. Check out the WebGL documentation and get started!

Posted by Jennifer Maurer, Software Engineer on the MapsGL team

Cross-posted on the Google Code Blog

Today we are introducing an early preview of Dart, a class-based optionally typed programming language for building web applications. Dart’s design goals are:

Create a structured yet flexible language for web programming.

Make Dart feel familiar and natural to programmers and thus easy to learn.

Ensure that Dart delivers high performance on all modern web browsers and environments ranging from small handheld devices to server-side execution.

Dart targets a wide range of development scenarios: from a one-person project without much structure to a large-scale project needing formal types in the code to state programmer intent. To support this wide range of projects, Dart has optional types; this means you can start coding without types and add them later as needed. We believe Dart will be great for writing large web applications.

Dart code can be executed in two different ways: either on a native virtual machine or on top of a JavaScript engine by using a compiler that translates Dart code to JavaScript. This means you can write a web application in Dart and have it compiled and run on any modern browser. The Dart VM is not currently integrated in Chrome but we plan to explore this option.

The language comes with a set of basic libraries and tools for checking, compiling, and running Dart code, all of which will evolve further with your participation. We've made the language and preliminary tools available as open source on dartlang.org. Check out the site to give feedback, learn more about Dart, and participate in its development.

We look forward to rapidly evolving Dart into a solid platform for structured web programming.

Posted by Lars Bak, Software Engineer

Are you already a happy user of Chrome Developer Tools but always wanted that particular feature added to make you even more productive? Then we have some exciting news for you: our developer tools are now extensible!

You can now add new panels and sidebar section panes, retrieve network requests data, evaluate scripts on the page being inspected, and add custom audit rules.



The extension support is still experimental, but we wanted to let you know early, so we can incorporate your feedback before releasing the APIs.

Here’s how to get started with writing extensions for Chrome Developer Tools:

• Use the dev channel of Chrome as the APIs are still under development;
• Enable experimental extension APIs using the chrome://flags page;
• List experimental in the permissions list of your extension;
• Add a devtools_page field to your extension’s manifest, e.g:

The developer tools extension pages get access to the chrome.experimental.devtools.* APIs which are described further in our docs. Be sure to check out the sample extensions, which include extensions for jQuery and FirePHP users and a simple audit extension that finds broken links.

For a richer example, you can also check out Page Speed for Chromium, which uses the extensions API to provide Page Speed suggestions right in the Chrome Devtools UI.

We’re looking forward to seeing your feedback on the APIs and, of course, cool extensions coming to life!

Posted by Andrey Kosyakov, Software Engineer