Thorsten Glaser, le dim. 12 janv. 2020 16:31:42 +0100, a ecrit: > > There is no need to start speech-dispatcher as root. Nowadays you can > > ah, okay. It did try to start it system-wide during package installation,
?? That's very surprising, we install it with --no-enable --no-start And the installation log on a freshly installed box confirms that default configuration: insserv: warning: current start runlevel(s) (empty) of script `speech-dispatcher` overrides LSB defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `speech-dispatcher` overrides LSB defaults (0 1 6). > So, we have the startup issues addressed, I think. Now, no sound, > although this might be a separate bugreport? As mentioned previously it can also be simply that orca isn't actually looking at the right place. Thus first testing with spd-say. > > spd-say "foo" > > > > and if that doesn't work, check out the log files in > > /run/user/1000/speech-dispatcher/log > > That path does not exist, but strace -e file showed there are logs in > /tmp/runtime-tglase/speech-dispatcher/log/ Ok, so that path varies with environments... > which I attached (as gzipped > tarball, although probably only speech-dispatcher.log has meaningful > informatioin). > > The logs contain info from exactly one spd-say invocation. Ok, thanks. > strace shows successful openat() of these sound-related devices: > /dev/snd/controlC0 /dev/snd/pcmC0D0p /dev/snd/timer Yes. The log shows two things: - only the dummy, generic, and mary-generic modules get enabled. You need to let apt install the recommended speech-dispatcher-espeak-ng package, in order to get at least one speech output backend. - the generic module gets to be recognized as "working" while it shouldn't even appear. speech-dispatcher thus doesn't default to dummy which would have told you of the situation. I'll have a look at that. (also, make sure in your mixer that the alsa output is not muted). Samuel