Hi I’m sorry, I should’ve been clearer. I didn’t mean to accuse debian guys of making a mistake, but rather that speech-dispatcher’s pulse audio code itself needs reworking, and that the debian guys who are maintaining speech dispatcher might want to, when they have time of course, take a look. I don’t remember the details, but luke said several times that speech dispatcher’s pulse audio code needed a lot of work, something about speech dispatcher using a simple API and pulse audio having a … a … oh what was it, more complex one but that speech dispatcher wasn’t using it? Something like that. I can try alsa or even better, libao. I’m hesitant to use speech dispatcher’s alsa backend because it’s even worse than it’s pulse backend. Especially with espeak. It hangs nearly constantly, and that’s with espeak, not espeak ng. I’m not even sure it would work with espeak ng. Also, I believe luke ripped it out. The only supported backends are now pulse or libao. I will try libao though. Again, I’m not absolutely certain speech dispatcher is at fault. I am fairly certain, since when I lose speech, orca starts but doesn’t speak, orca’s preferences open, progress bars beep, etc but there’s no speech. Fiddling with pulse audio will restore speech, for a little bit. I really wish in times like this orca would rely on espeak ng directly instead of going through speech dispatcher. I understand the logic both for and against sd, but at least have a backup so if problems like this come up you’re not left with no speech. Just think what would happen if a new user were hit with this. They’d probably conclude that Linux is buggy and doesn’t work well, run back to what they were using and … well you get the idea. I’m not trying to start a debate either, only pointing out that this isn’t a problem a new user would be able to solve. I’m able to limit the damage it does, but I can’t fix it. Thanks Kendell Clark Sent from Mail for Windows 10 From: Didier Spaier Hello Kendell, [quoted lines from kendell clark] > Followed by reinstalling pulse audio to restore the configuration. I can’t figure out why this works when there doesn’t seem to be anything wrong with pulse audio or it’s settings, but this fixes orca. For a little while, and then it messes up again in a few reboots. This is confusing, since all other apps that use pulse audio, like media players and the like continue to work, it’s only orca and speech dispatcher that are affected. Would the debian guys who maintain speech dispatcher mind taking a look at speech dispatcher’s pulse audio code and refactoring it? This is probably the source of the problem. I very much doubt that the pulse audio code in speech dispatcher be guilty. Rather I would suspect audio settings. I had a look at the building stuff of the Debian package in this compressed archive: http://http.debian.net/debian/pool/main/s/speech-dispatcher/speech-dispatcher_0.8.8-1.debian.tar.xz and didn't find anything weird. They just compile the source code with few patching. A patch set to use espeak-ng instead of espeak. We do the same in Slint, this can't hurt. Another patch (attached) just increase the default latency when using pulseaudio, I also doubt it comes into play. For what it's worth, you could try to rely on alsa instead of pulse as audio output method. That's what we do in Slint. If you want to try, first check that you have a working alsa backend in speech dispatcher, issuing this command: spd-conf --test-alsa If you hear a sound, as stated in the output, you can proceed to the next steps. First, either edit if it exists ~/.config/speech-dispatcher/speechd.conf, else /etc/speech-dispatcher/speechd.conf to have (uncommented): AudioOutputMethod "alsa" Alternatively, run as regular user: spd-conf After some questions you will hear this one: Default audio output method [pulse] : > type alsa then. Now to have output of speech-dispacher though alsa and output of other sound apps nicely coexisting you could edit /etc/pulse/default.pa to have these two lines included: load-module module-alsa-sink device=dmix load-module module-alsa-source device=dsnoop But also check that you don't have alsa output redirected to pulse: For instance if you have in /etc/asound.conf these two lines: pcm.default pulse ctl.default pulse comment them out or just remove them. Also, in Slint we make espeak-1.48.04 use portaudio, not pulseaudio. This is to have espeakup rely on alsa too in a console (text mode). So as a summary what I suggest is to have all speech apps relying to alsa, leaving pulseaudio used by other sound applications. Although I have no idea if this is applicable as-is to antergos, I hope this helps. Greetings, Dider Spaier Slint distribution: http://slint.fr |