support for additional deepgram config

[VinothRajasekar]

Summary of Changes

1. Addition of additional_config Parameter

• The STTOptions dataclass now includes an additional_config field, which is a dictionary for storing extra configuration parameters for deepgram.
• This allows users to pass parameters like paragraph and diarize when initializing the STT class.

2. Integration of additional_config in STT Initialization

• The STT class constructor now accepts an additional_config argument, which is then passed to the STTOptions dataclass.
• This dictionary dynamically updates configuration options during the _sanitize_options method call.

3. Dynamic Configuration Handling

• The _sanitize_options method has been updated to incorporate additional configuration options specified in additional_config.
• This ensures that any extra parameters are included in requests to the Deepgram API.

Example Usage

Users can now initialize the STT class with additional configuration parameters as follows:

from livekit.plugins import deepgram

stt_instance = deepgram.STT(
    additional_config={
        "paragraph": True,
        "diarize": True
    }
)

[changeset-bot]

🦋 Changeset detected

Latest commit: 2288c3f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
livekit-plugins-deepgram	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[CLAassistant]

All committers have signed the CLA.

[theomonnom]

Hey, I think it would be better to explicitly support those fields inside the constructor?

[VinothRajasekar]

Hey, I think it would be better to explicitly support those fields inside the constructor?

Hey, thanks for the feedback! Sorry for getting back late on this one. I completely understand the idea of making paragraph and diarize explicit in the constructor. However,I would like to highlight why keeping additional_config as the main way to pass deepgram parameters is a more scalable and flexible approach:

Avoids Frequent PRs & Code Changes
Deepgram continuously evolves, adding new parameters and features. If we hardcode specific parameters like paragraph and diarize inside our constructor, we’ll need to modify the code and submit a PR every time a new parameter is introduced or needs to be added

Maximizes Flexibility for Users
By keeping additional_config, we give users the freedom to pass any Deepgram-supported parameter dynamically without waiting for us to explicitly support it in the livekit deepgram plugin. This makes the integration more future-proof.

Deepgram Already Handles Validation
Deepgram itself validates the provided parameters. If a user mistakenly provides an invalid parameter, Deepgram returns appropriate error messages. This eliminates the need for us to maintain separate validation logic and ensures that we are always in sync with Deepgram’s latest updates.

Explicit Parameters Can Be Restrictive
While paragraph and diarize are useful today, there might be other parameters (e.g., model, tier, language) that different users might find more important. If we explicitly support some and not others, it provides some inflexibility and have to do a PR everytime to add new deepgram parameters.

please let me know what you think. thanks.