fixing [#868] bug where deepgram client fails due to langauge

[Vaibhav159]

Description:
This PR fixes a bug in the DeepgramSTTService where the language parameter, defined as an enum, was causing a WebSocket connection failure during the pipeline initialization. The issue occurred because Deepgram's API expects the language parameter as a string, but an enum was being passed directly.

Changes Made:

• Ensured the language parameter is converted from an enum to its string value (Language.EN.value) before being passed to the API.

[markbackman]

Thanks for the proposed fix!

For whatever reason I can't repro this, but this does seem like the right thing to do.

One suggestion, since it's also possible to pass a string via live_options, let's add a check like this:

if hasattr(merged_options.language, "value"):
    merged_options.language = merged_options.language.value

This will allow either a string of an enum to be passed. With that, I think this change is ready.

[Vaibhav-Lodha]

@markbackman this is up for review, lmk if there is any change required.

[markbackman]

Thank you! This is great.

[Vaibhav-Lodha]

@markbackman pushed once more change as per ruff, for some odd reason pycharm ruff didn't catch it 🤦

[markbackman]

The linter wants it as:

# deepgram connection requires language to be a string
if isinstance(merged_options.language, Language) and hasattr(
    merged_options.language, "value"
):
    merged_options.language = merged_options.language.value

That is, one less tab before merged_options.language, "value".

[jonnyjohnson1]

Had the same issue. This did the trick to make the deepgram client connect successfully, but it messed up the TTS audio (using elevenlabs) in the downstream frames.

[markbackman]

@jonnyjohnson1 do you mind filing a separate issue for what you're seeing with ElevenLabs? Might it be that the TTS audio issue is unrelated and now that the STT error is resolved, the TTS error is revealed?

[jonnyjohnson1]

Possibly. I'll create an issue for it