Description of problem: espeak-1.40.02-2.fc10 causes stardict to hung. espeak command espeak "Hello" does not produce any sounds and espeak itself does not finish. Ctrl-D does not work either. Version-Release number of selected component (if applicable): 1.40.02-2.fc10 How reproducible: Always Steps to Reproduce: 1. Install new version 1.40.02-2.fc10 Actual results: No sound, stardict hungs Expected results: Speech. Stardict should start properly. Additional info: OS -- Fedora 10 without pulseaudio (actually, only pulseaudio-libs-0.9.14-3.fc10.i386 presents)
*** Bug 518746 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This bug is still here in F12
ignore the last comment
I tried to revert from using pulseaudio to portaudio: - commented out the patch pulseaudio - copy src/portaudio19.h src/portaudio.h in %prep for it to compile I tested with command: $ espeak "Hello" and came out error messages about alsa. I installed alsa-* by yum. Then no error messages anymore. However, still no sounds.
Reboot the machine and it espeak works: $ espeak -s 100 "Hello" $ espeak -s 100 -w test.wav "How are you" and play test.wav with wav player.
(In reply to comment #7) > Reboot the machine and it espeak works: > > $ espeak -s 100 "Hello" > > $ espeak -s 100 -w test.wav "How are you" > > and play test.wav with wav player. This is a fairly well-known workaround, however it does not solve the issue of espeak not always producing sound when using portaudio (since you are simply creating a wave file with espeak, and using *another* program to actually play it) - this was the reason for the switch to pulseaudio to begin with (see bug #481651, for example). I will be pushing an update for espeak to the testing repos during the course of the day, and due to seemingly popular demand I'll attempt to revert to a working portaudio version. :-) My personal opinion is that the pulseaudio version (and using pulseaudio itself) works well and should be the way forward... however I understand that not everyone wants this, so let's try and find a solution that suits both parties.
So the real issue here is that espeak can be built against PulseAudio or PortAudio only at compile time. Now PortAudio is supposed to work with the PulseAudio ALSA plugin since I patched it for that, but there are several issues showing up with espeak in particular and I honestly don't know how to fix them (I wasn't able to reproduce them last I checked). So I'm not convinced reverting to using only PortAudio is a good idea. PulseAudio is after all the default audio solution in Fedora. Why do we even still try to support removing it at all? Of course the real solution would be to make this a runtime decision. A hackish solution would be to build espeak twice, once with PortAudio, once with PulseAudio, rename the binaries to espeak-portaudio and espeak-pulseaudio and turn espeak into a wrapper script which checks whether PulseAudio is running (the only question being how to best do that from a shell script) and invokes the correct version based on that.
(In reply to comment #9) > So the real issue here is that espeak can be built against PulseAudio or > PortAudio only at compile time. Yep, pretty much. > Now PortAudio is supposed to work with the PulseAudio ALSA plugin since I > patched it for that, but there are several issues showing up with espeak in > particular and I honestly don't know how to fix them (I wasn't able to > reproduce them last I checked). So I'm not convinced reverting to using only > PortAudio is a good idea. PulseAudio is after all the default audio solution in > Fedora. Why do we even still try to support removing it at all? I agree with you (and the portaudio fix works fine for me), but it has become clear that quite a few users dislike having to rely on pulseaudio for this to work) > Of course the real solution would be to make this a runtime decision. A hackish > solution would be to build espeak twice, once with PortAudio, once with > PulseAudio, rename the binaries to espeak-portaudio and espeak-pulseaudio and > turn espeak into a wrapper script which checks whether PulseAudio is running > (the only question being how to best do that from a shell script) and invokes > the correct version based on that. This is similar to what I was planning way back but abandonded based on the view that Fedora's default sound infrastructure is PulseAudio, and the hackish nature of it: My idea was to build espeak twice, but package the resulting binaries into separate espeak-portaudio and espeak-pulseaudio packages (splitting the data off into espeak-data), with a default "espeak" package pulling in espeak-pulseaudio and espeak-data... ugly, but would work. The problem with that approach, as well as the wrapper-script, is what to do with the shared library? Since *that* gets built against libpulse or libportaudio (i.e. resulting in 2 shared libs), which one would then be used for the -devel package? My initial feeling was to make the -portaudio version static, and use the pulseaudio version for the shared library, but that would really be just wrong. In other news, I've done a new espeak build (against portaudio) in koji, if anyone wants to test it: http://koji.fedoraproject.org/koji/buildinfo?buildID=147489 This works 100% for me... but I'm holding off pushing this into F-12 until we have some more feedback (going ahead on rawhide for now).
Created attachment 379035 [details] espeak-1.42.04-runtime-detection.patch This patch makes eSpeak check for PulseAudio at runtime and fall back to PortAudio if it's not available. This has passed my tests so far, but somebody should try it with PulseAudio not installed to make sure it works for them too.
PS: I wrote that patch (today).
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
(reopening this until I get some time to test Kevin's patch - thanks for writing it!)
(In reply to comment #8) > (In reply to comment #7) > > Reboot the machine and it espeak works: > > > > $ espeak -s 100 "Hello" > > > > $ espeak -s 100 -w test.wav "How are you" > > > > and play test.wav with wav player. > > This is a fairly well-known workaround, however it does not solve the issue of > espeak not always producing sound when using portaudio (since you are simply > creating a wave file with espeak, and using *another* program to actually play > it) - this was the reason for the switch to pulseaudio to begin with (see bug > #481651, for example). I understand. But given that current Fedora uses pulseaudio by default, I wonder why espeak was not built with that working? BTW, what is the reason of espeak not always producing sound when using portaudio?
My router with a minimal F12 installation is desperately awaiting an espeak working without pulsaudio. There is no graphical environment and no sound server daemon is required. Only sound output for the headless device. I want to remove my wrapper script with "espeak --stdout "$@" | aplay -q" in it. Is there a prebuild package of espeak for F12 available with the patch from comment #11 applied? I can do some tests to confirm the functionality.
So can you please apply my patch? I think it's better to apply it even without further testing than to let it sit there forever. It should fix the problems for the people not using PulseAudio without affecting PulseAudio users at all (and I tested it with PulseAudio and it definitely did work just as well as the current version without runtime checks), unlike the build you made for Rawhide which reverts to PortAudio and reintroduces the known issues there.
espeak-1.43-2.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/espeak-1.43-2.fc12
espeak-1.43-2.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/espeak-1.43-2.fc13
espeak-1.43-2.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update espeak'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-1368
espeak-1.43-2.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update espeak'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F13/FEDORA-2010-1382
I have installed espeak-1.43-2.fc12 in my pulsaudio free environment. There is a delay in the output and a message printed. Calling espeak direct I get this: --- # time espeak hello socket(): Address family not supported by protocol real 0m5.933s user 0m0.134s sys 0m0.067s # --- Calling the wrapper script "speak" with "espeak --stdout "$@" | aplay -q" in it I get this: --- # time speak hello real 0m0.856s user 0m0.075s sys 0m0.034s # ---
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.