Give main a shot, and if it works for you then I'll make a new release. Sorry about that--there were indeed two paths and I hadn't set the voice on one of them. Thanks for the report!

Setting the voice works in the main branch, but getting it doesn't. If I call Tts::voice, without calling Tts::speak first, the old voice will be returned.

Maybe it would make more sense for Tts::voice to return self.voice instead of calling self.synth.Voice(), although I think calling self.synth.SetVoice() when Tts::set_voice is called would be better, as it avoids having to store the Voice in the struct.

I'll open a PR, it's a quick fix :P. Is there any technical reason why you chose to store the voice, rate, pitch and volume in the struct itself? As I see it, calling the methods in SpeechSynthesizer directly would reduce the complexity of the struct, and also prevent errors like this one.

Isn't it possible to call all of these in their respective set methods, instead of doing it in every Tts::speak call?

self.synth.Options()?.SetSpeakingRate(self.rate.into())?;
self.synth.Options()?.SetAudioPitch(self.pitch.into())?;
self.synth.Options()?.SetAudioVolume(self.volume.into())?;
self.synth.SetVoice(&self.voice)?;

You would still have to store the voice because there is no way to convert from Voice to VoiceInformation in set_voice, but could remove self.pitch, self.rate and self.volume because you could pass the properties directly to the synth like this:

fn get_volume(&self) -> std::result::Result<f32, Error> {
    Ok(self.synth.Options()?.AudioVolume()? as f32)
}

fn set_volume(&mut self, volume: f32) -> std::result::Result<(), Error> {
    self.synth.Options()?.SetAudioVolume(volume as f64)?;
    Ok(())
}

Great! I'll give it a go :D