Ticket #4002 (closed defect: fixed)

Opened 7 years ago

Last modified 4 years ago

espeak fails on words starting with [ckpqtvz]

Reported by: MitchellNCharity Owned by: jg
Priority: high Milestone: Future Release
Component: distro Version:
Keywords: Cc: arjs, assim.deodia@…, goyal.hemant@…, raman@…, codyl, dgilmore
Action Needed: never set Verified: no
Deployments affected: Blocked By:
Blocking:

Description

Build 610, q2c27, B4. "espeak --stdout WORD | aplay - " is silent for words starting with any of the characters ckpqtvz.

Eg, all fail: c ca cat california. But all work: a ac at fcat aliforniac.

Hmm, also, "fac" fails. And fact factor fect fe fi fo fum. But "f" works.

We are currently using espeak 1.28. There has been a 1.29 since late August. Can we upgrade?

Change History

  Changed 7 years ago by jg

  • milestone changed from Never Assigned to First Deployment, V1.0

does 1.29 fix this?

  Changed 7 years ago by YChao

Same problem met with OS616, q2c27 on a B4. However, if using '-w' to write to a .wav file, it can be played with aplay well. Also tried with the pre-compiled espeak 1.29 from espeak.sf.net and it's of the same problem.

  Changed 7 years ago by arjs

  • cc arjs, assim.deodia@…, goyal.hemant@… added

We also couldn't get "hello" to be spoken. We are developing an e-Book reader that can read out text from Read Activity as part of our SOCON project, and therefore getting espeak to run correctly forms the basis of our project! Any suggestions/work-arounds ?

  Changed 7 years ago by jg

  • cc raman@… added
  • milestone changed from First Deployment, V1.0 to Opportunity (please help!)

Seems like someone needs to take the bull by the horns and see if they can figure out what's wrong with espeak, or whether one of the other releases works better.

It seems likely to me that something this basic would not slip through and I'd check if there is a configuration or build error causing problems. If you can diagnose what's wrong, we can get an updated package in the build.

Raman, do you have any suggestions?

  Changed 7 years ago by jonsd

Is this still a problem? My theory is that

espeak --stdout "hello" | aplay

May not work because it produces WAV output, but with length = 0 in the WAV header. This is because when it starts to produce the speech sound, it doesn't know how long it will be. espeak -w is OK because it writes to a file, and it can rewind and fill in the length information in the header after it has finished writing the speech sound data. But espeak --stdout can't do that.

So whether espeak --stdout is useful depends on whether the program which uses its output (aplay) can cope with "length = 0".

Is that the problem?

Alternatives are to write the speech to a file and then play it:

espeak -f temp.wav "hello"

Or use the espeak API to generate buffers of speech which your application can then play under its control. Or use espeak with its portaudio interface to play the sound.

  Changed 7 years ago by dking

The real reason this does not work is due to OSS not being emulated in the system ALSA install. Espeak uses OSS devices internal, that is why the 'direct to sound card' does not work at this time..

A bug has been opened on this.

  Changed 7 years ago by jg

  • milestone changed from Opportunity to Future Release

At this phase of the release cycle, I'm loathe to change the kernel configuration, and Alsa is/has been deployed for a long time.

What is more, we'll almost certainly move to an audio server in a future release (e.g. pulseaudio). OSS is not something I want dependencies on.

I might still consider a patch to fix espeak to use Alsa for Update.1, if one exists very soon, as we have no dependencies on espeak in the base system. If so, please nominate for update.1 and mail me (to make sure I notice immediately.

  Changed 7 years ago by jg

  • priority changed from normal to high

  Changed 7 years ago by dking

All that is required to fix this is some alias lines, and the loading of a few modules on startup. Its not a hard fix, and as somebody who works as an SDET with UNIX Systems Professionally I can say that I am ok enough with this fix that I did it on my own machine, and have had no issues or problems in all of my testing.

The main problem here is that most of the speech stuff your going to find that fits the needs of the XO project are going to have this issue; Nobody cares about speech synth except for the people who need it (Like the visualy impaired such as myself) or academia, and in the end that just means there are not the resources required to update things like espeak to the updated ALSA setup, since coding for OSS was much simpler at the time these applications where created and the entire design of them speaks to that (pun intended). As ALSA can emulate OSS fine with no problems and the fix is tested as working on my own XO, I have to say I do not see a problem with this fix.

What is your email?

  Changed 7 years ago by jg

  • cc codyl added

Mike Gorse writes:

Espeak needs OSS emulation if it is linked against Portaudio 18. If it is linked against Portaudio 19, then it uses the native ALSA api.

I'm not sure which version the XO has. If Portaudio 19 is being used, then a recent version from svn should be used or the speech server may lock up. Until recently, portaudio was calling snd_pcm_drain when recovering from a xrun, and snd_pcm_drain can lock up if dmix is used (unless this was fixed very recently). Portaudio 19 currently works around this by calling snd_pcm_drop instead of snd_pcm_drain.

-- Mike Gorse / AIM:linvortex / http://mgorse.freeshell.org --

follow-up: ↓ 12   Changed 7 years ago by jg

  • cc dgilmore added

As I said, I don't want OSS around, and I don't want to/will *not* change the kernel config at this late date for Update.1.

If someone gets a properly built ALSA based Espeak package to us ASAP (like this week), I can still consider waiving it into Update.1, as we have no current dependencies for it.

You can work with Dennis Gilmore on how to get this to happen.

If you do get such a package, then reassign this to "Retriage please!" so I see it.

in reply to: ↑ 11   Changed 7 years ago by AlbertCahalan

Replying to jg:

As I said, I don't want OSS around, and I don't want to/will *not* change the kernel config at this late date for Update.1.

OSS is the only API beyond SunOS-style /dev/audio that works everywhere. It works on Solaris, FreeBSD, SCO, and Linux. OSS is also far better documented than ALSA and far easier to program for. Having OSS will increase compatibility.

So, please do include it.

  Changed 7 years ago by jg

No, particularly *not* for Update.1. It's too late to be messing with our config file.

And there is a viable alternative to get espeak running immediately, without taking the risk of kernel configuration changes.

  Changed 6 years ago by ssb22

I had a conversation with eSpeak's author Jonathan Duddington some time ago about the length field that's written in --stdout. It's better to make it a very large number (as "sox" does) rather than 0. eSpeak does this now.

I can't remember the exact version that he fixed it in, but it's certianly fixed in eSpeak 1.35 which works absolutely fine on the XO when doing espeak --stdout | aplay -q (no kernel changes needed).

There have also been some important improvements in non-English languages.

  Changed 4 years ago by Quozl

  • status changed from new to closed
  • next_action set to never set
  • resolution set to fixed

OSS was shipped in 8.2.1 at least. espeak works fine there.

Note: See TracTickets for help on using tickets.