Q:

speech-dispatcher stopped working, spd-say starts, but stops after a few words

I have a problem with speech-dispatcher.  As stated: speech-dispatcher stopped working.  spd-say starts, but stops after a few words. 
To be more precise:

I had a longer text. ( This https://github.com/systemd/systemd/blob/master/NEWS from CHANGES WITH 246 until CHANGES WITH 245)
I fed it to spd-say: spd-say -l de -r 50 -t male1 "$(cat temp.txt)"
I noticed that it is reading English in German.  So I did killall speech-dispatcher.  Which is what actually brought me into trouble. 
I ran sudo service speech-dispatcher restart.  Then spd-say -l en -r 50 -t male1 "$(cat temp.txt)" It never finishes the second sentence.  The read out loud feature in Firefox also does not work anymore. 

I think it is generally not a good idea to use killall and I have missed the following options for spd-say:
-w, --wait          Wait till the message is spoken or discarded
-S, --stop          Stop speaking the message being spoken
-C, --cancel            Cancel all messages

Can someone please help me to get speech-dispatcher working again without rebooting or logging off and probably tell me how it is integrated in the gnome session, which seems to be the issue here since the system wide speech-dispatcher is disabled. 
Edit 1: Just booted up a VM and it fails there with the same text sample and also others.  I tried feeding it a bit less text, removing the leading white space and asterisks, but it still aborts in the middle of the second sentence.  In another example it stops after the first sentence (here: https://docs.ansible.com/ansible/latest/network/dev_guide/developing_plugins_network.html).  On the good side: I started using this command when I found no option in Firefox the read text on a page or file.  I just noticed that it at least can read the systemd changelog just fine. 
Edit 2: Firefox is working again, it just needed a restart after all of my fiddling trying to resolve the initial issue. 

A:

You need -w with spd-say to prevent that. 
Without it, spd-say will send the request to say something to speech-dispatcher, speech-dispatcher will say "okay, I'll do that!"  and soon after, spd-say will exit.  If speech-dispatcher hasn't finished talking at this point, it stops once spd-say exits. 
I don't know why the architectural decision was made too do it this way.  Because it was, it makes more sense to me that spd-say would have a --no-wait than a --wait, but I think we'd both agree that the documentation is not as clear on this point as it likely ought to be.