Implement missing speed functions along with durable speech rate / speed changer function.

[isikhi]

As I can see coqui tts repo contuniues on this repo. So i want to add same pr into this one. Thanks! Here is the details:

Added missing speed parameters to functions and ensured more durable, accurate speed adjustments with the new adjust_speech_rate function.

Base Repo Ref: coqui-ai#4115

[eginhard]

Thank you for the PR and sorry for the slow response! I would suggest a slightly different approach to support setting the speed for XTTS. Coqui has a bunch of different models where speed can be modified in different ways and for now I don't want to commit to a single method in api.py.

What will also work is to remove any reference to speed from api.py. If a speed argument is then specified by the user, it will then be automatically passed to models that can handle it via the **kwargs. Would you like to make these changes? Otherwise I can take care of it at some point.

[isikhi]

@eginhard thank you for the feedback! i am not entirely familiar with all the Coqui TTS models, but I guess I understand your suggestion. But i want to clarify again. are you recommending that instead of passing speed directly, I should rely on **kwargs to handle it dynamically?

For example, would this be closer to what you have in mind?

wav = self.tts(  
    text=text,  
    speaker=speaker,  
    language=language,  
    speaker_wav=speaker_wav,  
    split_sentences=split_sentences,  
    **kwargs,  # `speed` would be included here if specified by the user  and check in the body of function
)  

i guess with this way, any user-specified speed would automatically propagate to models that support it, without hardcoding it in api.py. please let me know if this aligns with your comment or if there’s another approach you’d prefer.

i am not advanced in python and coqui but i am happy to make further adjustments if i can do with your guidence.

[eginhard]

Exactly. What's currently blocking speed to be passed through the kwargs is that some functions in api.py have it as an explicit argument (although it's not actually used then), so after removing those it should just work.

[isikhi]

I was going to change and remove them from directly but then i realize for users whose version numbers are not strictly fixed, systems that call any function containing speed and use it in its current form might encounter issues (since there are no private accessors defined, making every function accessible). To avoid a BC (backward compatibility) break, I believe it would be more appropriate to leave speed as it is. However, if a BC break is not a concern and we are planning to release a new major version, I can proceed with the changes.

[eginhard]

Well before you couldn't set speed and after that change you can, so that is an improvement and doesn't really break anything :)