[jaunty karmic] espeak missing words and phonemes from sentences

Bug #377060 reported by moma
72
This bug affects 11 people
Affects Status Importance Assigned to Milestone
espeak (Ubuntu)
Fix Released
Medium
Ubuntu Audio Team
Declined for Karmic by Daniel T Chen

Bug Description

Hello,

A tiny test of Espeak speech synhesizer:
If I run the following command several times, espeak sometime looses the beginning of statement and starts to speak from "help me to find...". I simply repeat the command rather quickly several times.

echo "I beg your pardon, could you help me to find this address." | espeak

Another example
echo "All your base are belong to us. Do you agree?" | espeak -v en-us -p 10 -s 140

The active sound card is:
lspci | grep -i audio
04:02.0 Multimedia audio controller: Creative Labs SB0400 Audigy2 Value

==================

Possible fix/patch:

I got the sources, and noticed in the Makefile:
AUDIO = portaudio
#AUDIO = pulseaudio
#AUDIO = sada

But guess what? ubuntu now uses pulse... I simply changed it to...
#AUDIO = portaudio
AUDIO = pulseaudio
#AUDIO = sada
.. Recompiled.. stumbled (needed to install libpulse-dev)... and Yipee!!!

Revision history for this message
Mr. Mike (mike-himikeb) wrote :

I can confirm espeak is broken. I've tried on at least 3 computers with various hardware configurations - laptops, desktops, fast, slow, all 32-bit Jaunty.

Mostly, it plays super-duper fast (like, an entire sentence in a fraction of a second).

On two computers, I received the following messages until I uninstalled bluez-alsa.
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
And now, it plays a sentence, but it comes out so fast it's like just a tick.

As posted elsewhere on the web, the wav generation appears to work, eg:
#!/bin/sh
espeak -w ~/.espk.wav "$1"
aplay ~/.espk.wav
rm ~/.espk.wav

does work.

Revision history for this message
Mr. Mike (mike-himikeb) wrote :

I'm tired of just complaining and want to help... and...
I FIXED IT!! My First Linux Bug-fix - YAY!!!

Having said that, hopefully someone who can actually implement this for Ubuntu can get it into the distro.
I got the sources, and noticed in the Makefile:
AUDIO = portaudio
#AUDIO = pulseaudio
#AUDIO = sada

But guess what? ubuntu now uses pulse... I simply changed it to...
#AUDIO = portaudio
AUDIO = pulseaudio
#AUDIO = sada
.. Recompiled.. stumbled (needed to install libpulse-dev)... and Yipee!!!

Revision history for this message
xteejx (xteejx) wrote :

I am also seeing this in Karmic alpha 1. It doesn't seem to matter what is typed, it will lose bits of words or sometimes even 1 or 2 words if they play after each other too quickly. Have to wait 5-10 seconds before it will talk again properly.
Setting Confirmed, Low.

Changed in espeak (Ubuntu):
importance: Undecided → Low
status: New → Confirmed
summary: - Jaunty 64bit: Espeak looses some words.
+ [jaunty karmic] espeak missing words and phonemes from sentences
Revision history for this message
David Sugar (dyfet-deactivatedaccount) wrote :

This ties into the larger issue of untangling audio in Ubuntu. The latest release of portaudio has some problems with the alsa & pulse backend, and this is what breaks espeak. But what to do? We can compile espeak natively to use pulse rather than using portaudio, but until/unless pulse becomes the default backend, this does not make sense to do on a distribution basis. I think the short term goal is to make portaudio work properly again, which will fix this for (or hopefully much before) Karmic. Hence, I suggest this issue be tied to or otherwise noted in portaudio as well.

Revision history for this message
gururise (gururise) wrote :

I too am having problems with espeak cutting off the first word or couple words of a sentence. Running Ubuntu 9.04 fully updated 64-bit system.

I may try re-compiling espeak to use pulse.

Revision history for this message
Reuben Firmin (reubenf) wrote :

Can I suggest raising the priority on this? This makes espeak unusable for accessibility purposes.

Revision history for this message
Chris Cowan (macil) wrote :

I'm having similar trouble still. I've called espeak multiple times in a row with a single word or so ("a", "test", etc), and about 50% of the time it doesn't work. Sometimes it just lets out a short blip of noise. Other times it works fine. I'm figure this is related to this bug post.

Ubuntu 9.04 fully updated 64-bit system just like gururise.

Revision history for this message
Ed Davies (lp-od-0909) wrote :

I'm having the problem described by Mr Mike on 2009-06-03: "And now, it plays a sentence, but it comes out so fast it's like just a tick." A long utterance (a many line text file) comes out as a sequence of rapid ticks. 32-bit Jaunty.

I think it needs to be higher than "low" priority: espeak doesn't work at all here in its normal mode of operation.

A slightly less wordy workaround, though:

$ espeak --stdout "Hello world" | aplay -q

Revision history for this message
Norberto (norberto-thegame) wrote :

espeak not working in jaunty is qute inconvinient for me as I use it for accessibility purposes to have it read text to me tha ti hightlight from applications. I hope this gets fixed for next release.

xteejx (xteejx)
description: updated
Revision history for this message
Daniel Ellis (danellisuk) wrote :

I am going to assign this to the Ubuntu Audio Team as this probably is not an issue specifically with espeak. As noted by David Sugar in comment 4, this is a problem with portaudio not working correctly with pulseaudio.

Changed in espeak (Ubuntu):
assignee: nobody → Ubuntu Audio Team (ubuntu-audio)
Revision history for this message
logari81 (logari81) wrote :

@Luke Yelavich:
according to change log you are the maintainer of this package. Please update it for pulseaudio support. Attached you can find the corresponding debdiff. Don't forget to leave out my entry from the changelog file.

@people who need an easy fix until the package in repo is fixed:
Install it from here
https://launchpad.net/~logari81/+archive/ppa
it has been tested on jaunty and karmic

Revision history for this message
sterios prosiniklis (steriosprosiniklis) wrote :

Karmic
Fix confirmed using package from
https://launchpad.net/~logari81/+archive/ppa

Revision history for this message
Daniel T Chen (crimsun) wrote :

It's a non-trivial change for an already-released Ubuntu version. For Lucid, we should either replace the build-dep on portaudio19-dev with libpulse-dev, or we should generate split sets targeting both portaudio and pulse. Both approaches are not without drawbacks. In the former, it will cause non-PulseAudio-using derivatives (Kubuntu, Xubuntu) to pull in PulseAudio as a hard requirement for espeak to work correctly. In the latter, we would need to juggle transitions for the shared lib, the statically linked lib, and the dev package.

Daniel T Chen (crimsun)
Changed in espeak (Ubuntu):
importance: Low → Medium
Revision history for this message
xteejx (xteejx) wrote :

Am I right in thinking that this is being, or has been worked on for Lucid? Can we change to Fix Released yet?

Revision history for this message
logari81 (logari81) wrote :

As I can see the current package in Lucid is still based on portaudio so I believe it still works in Kubuntu and is still broken in Ubuntu.
Fedora has also decided to enable pulseaudio support by default:
http://cvs.fedoraproject.org/viewvc/rpms/espeak/F-12/espeak-1.40.02-pulseaudio.patch?revision=1.1&view=markup

I think firstly we should fix the current package to work with pulseaudio in Ubuntu and secondly we should provide an alternative package for use with portaudio in Kubuntu.

Since this problem affects many educational applications, I believe it is very important to be fixed.

Revision history for this message
Attila Hammer (hammera) wrote : Re: [Bug 377060] Re: [jaunty karmic] espeak missing words and phonemes from sentences

I not see problem when I using Speech-dispatcher and a Modifyed pulse
driver.
When I using Orca screen reader with GNOME-Speech driver, the bug is
present.

Attila

Revision history for this message
Eddie Hung (eddieh) wrote :

I cannot seem to reproduce this bug by repeatedly running (each execution immediately follows the end of the previous execution):
echo "I beg your pardon, could you help me to find this address." | espeak
on the latest lucid distribution

David Futcher (bobbo)
tags: added: patch-needswork
Revision history for this message
xteejx (xteejx) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner.
There have been many changes in Ubuntu since the time of the last comment and your problem may have been fixed with some of the updates. It would help us a lot if you could test the current Ubuntu version (10.10). If you can test it, and it is still an issue, we would appreciate if you could upload updated logs by running apport-collect <bug #>, and any other logs that are relevant for this particular issue.

Changed in espeak (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Edavies (edavies) wrote :

Now works for me on Lucid 32-bit Ubuntu upgraded from Jaunty system whose failure is reported above. Sorry, don't remember what state it was in on Karmic.

Revision history for this message
xteejx (xteejx) wrote :

Brilliant! Thank you for the reply. This bug report is being closed due to your last comment regarding this being fixed with an update. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.

Changed in espeak (Ubuntu):
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.