3 ms·

While I think this client library is brilliant, this is the worst possible approach to the problem. I'm working on an iPad app using PhoneGap to help people wit

by chime 15y ago

While I think this client library is brilliant, this is the worst possible approach to the problem. I'm working on an iPad app using PhoneGap to help people with speech+motor disabilities communicate (http://ktype.net http://ktype.net). All I want is a window.speak() function that works with minimal delay. Give me the ability to select one of the standard voices, pitch/tempo, volume, and feed it the text to say. Callbacks/events would be nice too. This kind of stuff should be part of HTML5 and not just input[type=range]. Most OSs from Windows to iOS includes text-to-speech for accessibility. Why can't we hook into it from the browser? Give me a list of available voices/types (gender, country, accent), make all the other parameters 0.0-1.0, and I'll be a happy dev.

dstein 15y ago
I agree that it's pretty stupid that we have to go to these lengths to enable TTS. Both iOS and Android already have these capabilities. The technology is there but Apple and Google don't enable any JavaScript API's presumably to solidify their native platforms as the only way to develop. You should be thanking Mozilla for building an Audio Data API capable of features like this, and not wait for Apple and Google to get their heads out of their asses.
azakai 15y ago
I am not sure using the system speech libraries is the best solution. You will get different results depending on the OS. Which means you will need to test with all OSes (and all versions of those OSes). And each will have its own list of available voices and languages, etc. Whereas if you use a JS library in your project, you will know exactly how things will sound, you can include exactly the voices and languages you want, and only have to test once.
- chime 15y ago
  > You will get different results depending on the OS. Would be no different than making web pages. Even JS isn't same across browsers. The big question is do I want to use a JS-TTS library or native and I think native will always be better performance/resource wise. > And each will have its own list of available voices and languages, etc. That can easily be solved by window.speech.listvoices like I mentioned in my post above. > exactly how things will sound, you can include exactly the voices and languages you want, and only have to test once. I've been programming for 20 years and that hasn't happened for any system, ever, not even once. You always have to test on different devices, OSs, platforms, browsers etc.
  - azakai 15y ago
    I agree that making web pages takes a lot of testing on different browsers and OSes. And that, as you said, there is no write-once-run-anywhere in software. But I think we should minimize the problem, not make it worse. Having the same JS TTS gets you much closer to the ideal, using system TTS gets you farther. I do agree that a native library will have better performance, I am estimating something like 3-5X faster in the near future. So that is a benefit to the system TTS approach. But even the fairly unoptimized version in this online demo isn't too slow to be useful, I don't think, and it can be made much faster if necessary. I haven't focused on speed yet. My concern with each OS having its own voices is that the names of the voices aren't enough to know what your users will hear. Unless we have a standard for TTS that includes the actual voice data, otherwise say "male UK English" may sound very different on different platforms. It's clear there are tradeoffs here, both ways, and you make sound points. But I prefer the JS TTS approach, unless you are writing something like an iPad-specific app. If you don't care about other platforms, then I agree, system TTS is better.
- chime 15y ago
  Just want to reiterate that regardless of my opposition to JS-TTS right now, I think this library is brilliant and it works in Chrome on OS X perfectly. Maybe in a few more years, JS performance for such tasks will be commonplace just like making browser add-ons in JS was unthinkable ten years ago but is standard now. However, I still feel the platform/browser should provide TTS features by default.

by chime 15y ago

dstein 15y ago

I agree that it's pretty stupid that we have to go to these lengths to enable TTS. Both iOS and Android already have these capabilities. The technology is there but Apple and Google don't enable any JavaScript API's presumably to solidify their native platforms as the only way to develop. You should be thanking Mozilla for building an Audio Data API capable of features like this, and not wait for Apple and Google to get their heads out of their asses.

azakai 15y ago

I am not sure using the system speech libraries is the best solution. You will get different results depending on the OS. Which means you will need to test with all OSes (and all versions of those OSes). And each will have its own list of available voices and languages, etc. Whereas if you use a JS library in your project, you will know exactly how things will sound, you can include exactly the voices and languages you want, and only have to test once.

chime 15y ago
> You will get different results depending on the OS. Would be no different than making web pages. Even JS isn't same across browsers. The big question is do I want to use a JS-TTS library or native and I think native will always be better performance/resource wise. > And each will have its own list of available voices and languages, etc. That can easily be solved by window.speech.listvoices like I mentioned in my post above. > exactly how things will sound, you can include exactly the voices and languages you want, and only have to test once. I've been programming for 20 years and that hasn't happened for any system, ever, not even once. You always have to test on different devices, OSs, platforms, browsers etc.
- azakai 15y ago
  I agree that making web pages takes a lot of testing on different browsers and OSes. And that, as you said, there is no write-once-run-anywhere in software. But I think we should minimize the problem, not make it worse. Having the same JS TTS gets you much closer to the ideal, using system TTS gets you farther. I do agree that a native library will have better performance, I am estimating something like 3-5X faster in the near future. So that is a benefit to the system TTS approach. But even the fairly unoptimized version in this online demo isn't too slow to be useful, I don't think, and it can be made much faster if necessary. I haven't focused on speed yet. My concern with each OS having its own voices is that the names of the voices aren't enough to know what your users will hear. Unless we have a standard for TTS that includes the actual voice data, otherwise say "male UK English" may sound very different on different platforms. It's clear there are tradeoffs here, both ways, and you make sound points. But I prefer the JS TTS approach, unless you are writing something like an iPad-specific app. If you don't care about other platforms, then I agree, system TTS is better.
chime 15y ago
Just want to reiterate that regardless of my opposition to JS-TTS right now, I think this library is brilliant and it works in Chrome on OS X perfectly. Maybe in a few more years, JS performance for such tasks will be commonplace just like making browser add-ons in JS was unthinkable ten years ago but is standard now. However, I still feel the platform/browser should provide TTS features by default.