Description of problem:I'm unable to get speech-dispatcher to speak using espeak as my ordinary user. It works for root, but not for uid #1000. /var/log/speech-dispatcher/espeak.log reports "Cannot initialize Alsa device 'plughw:2,0'," yet an aplay to that device works perfectly, both for my ordinary user and for root. Also, this was working with F16 Alpha. It broke when I did a clean install of F16 beta. Version-Release number of selected component (if applicable):0.7.1-6 How reproducible: Always. Steps to Reproduce: 1.Verify alsa loaded and working 2.Verify 'speech-dispatcherd status' 3.Do 'spd-say hello' Actual results: Bash prompt does not return, requires Ctrl-C Expected results: Should hear espeak voice "hello" . Additional info:
Because a nonfunction Speech Dispatcher renders Orca unusable, and because I had had no problems using these with Fedora 15 previously, I down versioned with a clean install of F-15 this past week. Regretably, this problem has now infected F-15 as well. Inasmuch as the SD build provided for F-15 is dated this past March, it's clear that some other update has rendered SD unusable. Symptoms are exactly as described above. The root user gets speech, but the ordinary user does not. Furthermore, the audio device is locked when an ordinary user attempts to use SD, and a manual kill is needed to kill the orphan process holding the device. Please give this problem urgent attention. There is simply no other available recourse for the speech dependent Orca user. Let me know what other info I can provide.
works for me, on an f16 box. actually works the opposite to you: doesn't work for root (though it just returns without saying anything, rather than hanging), does work for user. does it work if you disable selinux? can you strace the command and see where it hangs?
for added lulz I recommend the test text "fitter, happier, more productive"
Created attachment 530414 [details] strace for 'spd-say hello' re bug 743762
Also set selinux=disabled in /etc/sysconfig/selinux and rebooted. Same results. I note the strace output complains "connection refused" accessing /home/janina/.speech-dispatcher/speechd.sock which is chown janina:janina and chmod srwxrwx---
can we get ls -lZ ~/.speech-dispatcher and ls -lDz ~/.speech-dispatcher just to be sure? thanks
erf, last one should be ls -ldZ ~/.speech-dispatcher
janina@sonata 21:34:44 ~$ls -lZ ~/.speech-dispatcher drwx------. janina janina unconfined_u:object_r:user_home_t:s0 log drwx------. janina janina unconfined_u:object_r:user_home_t:s0 pid srwxrwx--- janina janina ? speechd.sock janina@sonata 21:34:50 ~$ls -ldZ ~/.speech-dispatcher drwx------. janina janina unconfined_u:object_r:user_home_t:s0 /home/janina/.speech-dispatcher
I tried this on my F16 laptop and get the same results as Adam Williamson. Speech happens as expected for normal user. I don't normally use or test orca and removed .local/share/orca before trying. Is it possible this is a sound configuration problem?
I don't see any issues on F-16, and I know of a number of people using it without issues on F-15. We default to using PulseAudio so that we don't have issues with other devices accessing the sound card. Can you give more details about your configuration, and espeak config?
Sure, but please also note that it also used to work for me on both F15 and F16. The SD hasn't changed, nor has my audio configuration. aplay, mplayer, etc., all work until spd-say hangs the device. Finding and killing the orphaned pid holding the audio device restores it, i.e. aplay works again. My audio setup: SD configured via /etc/speech-dispatcher/speechd.conf: AudioOutputMethod "alsa" AudioALSADevice "plughw:2,0" Other values tweaked, e.g. volume, rate, etc. espeak.conf is untouched. pulseaudio disabled via commenting the call in /etc/asound.conf. It may be the default, but it's a nonstarter for a screen reader user on the console. Lastly, /etc/modprobe.d/local.conf has stanzas like: alias snd-card-2 snd-usb-audio options snd-card-2 index=2 options snd-usb-audio index=2 Certainly, I would prefer to mix streams, dmix or pa, but I've isolated a device specifically for sd. As I said, it plays perfectly, even for root with sd, just not for user, though it used to work for user as well.
OK, I tried a few things. First, I enabled pa--same results. Then, I edited speechd.conf to use inet sockets on localhost. While it didn't work, it actually gave errors rather than simply hanging (another bug, I guess) janina@sonata 19:02:08 ~$spd-say hello 2>&1 Failed to connect to Speech Dispatcher: Error: Can't connect to unix socket /home/janina/.speech-dispatcher/speechd.sock: Connection refused. Autospawn: Autospawn +failed. Speech Dispatcher refused to start with error code, stating this as a reason: Error: can't open logging file +/var/log/speech-dispatcher//speechd.log! Using stdout. Thu Oct 27 19:02:22 2011 [184686] ALSA ERROR: Cannot open audio device plughw:2,0 (Device or resource busy) Thu Oct 27 19:02:22 2011 [184717] ALSA ERROR: Cannot initialize Alsa device 'plughw:2,0': Can't open. festival_client: connect to server failed Error: can't open logging file /var/log/speech-dispatcher//speechd.log! Using stdout. Autospawn failed: Mismatch in communication methods. Client requests unix_socket, most probably due to its configuration or the value of the SPEECHD_ADDRESS environment variable, but the server is configured to provide the inet_socket method.How so still looking for unix sockets? And how so can't write a log? Dir is 700 and root:root; file is 660 and root:root.
It doesn't look like you commented out the audio device settings in the speech-dispatcher configuration when you enabled PulseAudio. So it was still trying to open an ALSA device that's claimed already. If it were me I'd probably want to also restart the system after enabling PulseAudio and making the speech-dispatcher changes, just to know that some errant process wasn't still claiming the device. I wouldn't mix and match the inet socket stuff at the same time, that just adds more variables and makes the problem harder to find.
Also, that inability to use the log file bugs me too. I can't reproduce that here either, which tells me that you have either a permissions problem or a missing or wrong SELinux label somewhere. This could easily happen if you tend to disable SELinux rather than setting it as permissive when testing. New files don't get labeled when that happens, so you can run into problems down the line. Before you reboot, use the 'su' or 'sudo' command to run the following command as root: touch /.autorelabel When you reboot, expect a sizable delay while SELinux relabels your files. Then try again. If you need to turn off SELinux to see if it's not working, again, use the 'su' or 'sudo' command to run the following command as root: setenforce 0 To turn SELinux back on, run: setenforce 1 This is a much easier and less error-prone way to determine whether SELinux has any bearing on a particular issue. When enforcement is off, any SELinux error is still logged, but the access is no longer denied -- so if that makes a difference you know that SELinux labeling has some relation to the error.
Speaking of which, I also just spotted another problem in your ~/.speech-dispatcher files: srwxrwx--- janina janina ? speechd.sock You're missing the SELinux label here, and this might cause problems when SELinux enforcement is on. Do this as root using 'su' or 'sudo': restorecon -v /home/janina/.speech-dispatcher/speechd.sock Make sure you've reverted the configuration files for /etc/speech-dispatcher/speechd.conf so that again you're not dealing with extra variables. Then try again. With this variety of problems, I have little confidence this is an actual bug in Fedora 15 or 16. However, I'm willing to help out as best I can via this bug over the next couple of days to resolve. If it stretches beyond that, without any further evidence this is reproducible beyond Janina's own system, I would recommend this be CLOSED WORKSFORME.
The .autolabel fixed it. I'm back in enforcing mode and SD is working. THANK YOU! Just to follow up on recent comments: My tests with PA and with SD set for inet_socket were two separate tests, separated by reboots. 1.)The restorecon -v on my socket (run as root) showed no output, which I interpret as no change made. That leaves me curious whether .autolabel and restorecon -vr / -- not the same? In any case, whether this was my config problem or a Fedora bug -- I'm happy to chase down further, if desired. Let me reiterate this showed up immediately following a fresh install of F15, where the hd was reformatted (to eliminate LVM), then /home/* was restored from a backup drive. Subsequently, when SD didn't work, I also tried yum reinstall. In fact, I tried a couple reinstalls, including my own rpmbuild. So, is it worth chasing down which selinux setting on which file? I can't be the only one who will try and preserve $HOME across installs. Interesting also that running with selinux=disabled didn't fix the problem.
Not sure about the restore details, but it's quite possible that's where the problem arose. Whether you touch /.autorelabel or restorecon -vr / you are essentially doing the same thing -- relabeling the entire file system with SELinux labels that are up to date with the latest policy. This tends to fix a wide variety of problems that occur when SELinux is disabled temporarily, or if files are moved around manually. It's not a bad idea any time you migrate a large amount of data, because not all methods of moving, copying, or restoring files treat the SELinux labels properly. I'm convinced this is not a Fedora bug, and that there's no SELinux problem here for you to chase down further. So with Peter's indulgence I'm going to CLOSE NOTABUG. (That seems more collegial than WORKSFORME.)
Regretably, the fix was ephemeral. It's stopped working. The behavior is different in that it no longer hangs, it simply exits silently. No error--but also no speech. Unfortunately, I'm unable to work on this further just now as I have duties at next week's W3C Technical Plennary. So, perhaps this is a "Works ForYou" for now! <grin> Needless to say, I'll be bak on this issue for myself, as it's the showstopper that keeps me from using any of the graphical desktop.