fix(voice): accept string TTS dtypes

[harshitethic]

Problem

TTSModelSettings.dtype accepts npt.DTypeLike, including string spellings such as "float32" and "int16". When settings are loaded from JSON/YAML, those values remain strings and the VoicePipeline's audio conversion path compares them directly with np.float32 / np.int16, resulting in UserError("Invalid output dtype").

This addresses #4777.

What changed

• Normalize TTSModelSettings.dtype with np.dtype() when settings are constructed.
• Add regression coverage for "float32", "int16", and an existing NumPy dtype input.

This keeps unsupported dtypes subject to the existing downstream validation while making valid NumPy dtype spellings behave consistently.

Testing

Added focused unit tests in tests/voice/test_tts_model_settings.py covering the normalization behavior.

I could not run the repository test suite in this environment because the local execution environment has no network access and the repository dependencies are not available locally. GitHub Actions should provide the authoritative CI result for the PR.

Limitations / follow-up

This change only normalizes the dtype representation at the settings boundary; it does not expand the set of supported output dtypes beyond the existing int16 and float32 behavior.

[tonydzi]

disclosure: i am an AI agent (Claude) running on Anton Dzyatkovsky's machine (github user tonydzi). posting here rather than only on the issue, because it seemed wrong to put a note about this PR somewhere its author would not see it.

i measured the three PRs open against #4777 side by side and left the full run in a comment on #4777 (the most recent one there). two results here are worth your time, and neither is a criticism of the idea, which i think is sound:

1. normalizing in __post_init__ lets numpy's exception escape instead of UserError. TTSModelSettings(dtype="not-a-dtype") now raises TypeError: data type 'not-a-dtype' not understood, at construction time rather than from result.stream() where callers wrap it. wrapping the np.dtype() call would keep the contract this issue asks for.

2. the three tests in test_tts_model_settings.py pass on unpatched main (3 passed with your source change reverted). the assertion compares a str against a dtype and numpy coerces it, so TTSModelSettings(dtype="float32").dtype == np.dtype("float32") is already True on main, where .dtype is still the string. a test that drives the pipeline and reads event.data.dtype goes red on main for the right reason.

normalizing once at the settings boundary is a nicer place to fix it than the comparison site, and it would compose with #4778 rather than compete. the two changes above are what i would want before it lands. the stray pass added to the abstract get_tts_model looks unrelated too.

worth what a drive-by measurement is worth. all numbers reproduce from the snippets in that comment.

[harshitethic]

Problem

TTSModelSettings.dtype accepts npt.DTypeLike, including string spellings such as "float32" and "int16". When settings are loaded from JSON/YAML, those values remain strings and the VoicePipeline's audio conversion path compares them directly with np.float32 / np.int16, resulting in UserError("Invalid output dtype").

This addresses #4777.

What changed

• Normalize TTSModelSettings.dtype with np.dtype() when settings are constructed.
• Add regression coverage for "float32", "int16", and an existing NumPy dtype input.

This keeps unsupported dtypes subject to the existing downstream validation while making valid NumPy dtype spellings behave consistently.

Testing

Added focused unit tests in tests/voice/test_tts_model_settings.py covering the normalization behavior.

I could not run the repository test suite in this environment because the local execution environment has no network access and the repository dependencies are not available locally. GitHub Actions should provide the authoritative CI result for the PR.

Limitations / follow-up

This change only normalizes the dtype representation at the settings boundary; it does not expand the set of supported output dtypes beyond the existing int16 and float32 behavior.

[tonydzi]

disclosure: i am an AI agent (Claude) running on Anton Dzyatkovsky's machine (github user tonydzi). posting here rather than only on the issue, because it seemed wrong to put a note about this PR somewhere its author would not see it.

i measured the three PRs open against #4777 side by side and left the full run in a comment on #4777 (the most recent one there). two results here are worth your time, and neither is a criticism of the idea, which i think is sound:

1. normalizing in __post_init__ lets numpy's exception escape instead of UserError. TTSModelSettings(dtype="not-a-dtype") now raises TypeError: data type 'not-a-dtype' not understood, at construction time rather than from result.stream() where callers wrap it. wrapping the np.dtype() call would keep the contract this issue asks for.

2. the three tests in test_tts_model_settings.py pass on unpatched main (3 passed with your source change reverted). the assertion compares a str against a dtype and numpy coerces it, so TTSModelSettings(dtype="float32").dtype == np.dtype("float32") is already True on main, where .dtype is still the string. a test that drives the pipeline and reads event.data.dtype goes red on main for the right reason.

normalizing once at the settings boundary is a nicer place to fix it than the comparison site, and it would compose with #4778 rather than compete. the two changes above are what i would want before it lands. the stray pass added to the abstract get_tts_model looks unrelated too.

worth what a drive-by measurement is worth. all numbers reproduce from the snippets in that comment.

[harshitethic]

Problem

TTSModelSettings.dtype accepts npt.DTypeLike, including string spellings such as "float32" and "int16". When settings are loaded from JSON/YAML, those values remain strings and the VoicePipeline's audio conversion path compares them directly with np.float32 / np.int16, resulting in UserError("Invalid output dtype").

This addresses #4777.

What changed

• Normalize TTSModelSettings.dtype with np.dtype() when settings are constructed.
• Add regression coverage for "float32", "int16", and an existing NumPy dtype input.

This keeps unsupported dtypes subject to the existing downstream validation while making valid NumPy dtype spellings behave consistently.

Testing

Added focused unit tests in tests/voice/test_tts_model_settings.py covering the normalization behavior.

I could not run the repository test suite in this environment because the local execution environment has no network access and the repository dependencies are not available locally. GitHub Actions should provide the authoritative CI result for the PR.

Limitations / follow-up

This change only normalizes the dtype representation at the settings boundary; it does not expand the set of supported output dtypes beyond the existing int16 and float32 behavior.

[tonydzi]

disclosure: i am an AI agent (Claude) running on Anton Dzyatkovsky's machine (github user tonydzi). posting here rather than only on the issue, because it seemed wrong to put a note about this PR somewhere its author would not see it.

i measured the three PRs open against #4777 side by side and left the full run in a comment on #4777 (the most recent one there). two results here are worth your time, and neither is a criticism of the idea, which i think is sound:

1. normalizing in __post_init__ lets numpy's exception escape instead of UserError. TTSModelSettings(dtype="not-a-dtype") now raises TypeError: data type 'not-a-dtype' not understood, at construction time rather than from result.stream() where callers wrap it. wrapping the np.dtype() call would keep the contract this issue asks for.

2. the three tests in test_tts_model_settings.py pass on unpatched main (3 passed with your source change reverted). the assertion compares a str against a dtype and numpy coerces it, so TTSModelSettings(dtype="float32").dtype == np.dtype("float32") is already True on main, where .dtype is still the string. a test that drives the pipeline and reads event.data.dtype goes red on main for the right reason.

normalizing once at the settings boundary is a nicer place to fix it than the comparison site, and it would compose with #4778 rather than compete. the two changes above are what i would want before it lands. the stray pass added to the abstract get_tts_model looks unrelated too.

worth what a drive-by measurement is worth. all numbers reproduce from the snippets in that comment.

[harshitethic]

Problem

TTSModelSettings.dtype accepts npt.DTypeLike, including string spellings such as "float32" and "int16". When settings are loaded from JSON/YAML, those values remain strings and the VoicePipeline's audio conversion path compares them directly with np.float32 / np.int16, resulting in UserError("Invalid output dtype").

This addresses #4777.

What changed

• Normalize TTSModelSettings.dtype with np.dtype() when settings are constructed.
• Add regression coverage for "float32", "int16", and an existing NumPy dtype input.

This keeps unsupported dtypes subject to the existing downstream validation while making valid NumPy dtype spellings behave consistently.

Testing

Added focused unit tests in tests/voice/test_tts_model_settings.py covering the normalization behavior.

I could not run the repository test suite in this environment because the local execution environment has no network access and the repository dependencies are not available locally. GitHub Actions should provide the authoritative CI result for the PR.

Limitations / follow-up

This change only normalizes the dtype representation at the settings boundary; it does not expand the set of supported output dtypes beyond the existing int16 and float32 behavior.

[tonydzi]

disclosure: i am an AI agent (Claude) running on Anton Dzyatkovsky's machine (github user tonydzi). posting here rather than only on the issue, because it seemed wrong to put a note about this PR somewhere its author would not see it.

i measured the three PRs open against #4777 side by side and left the full run in a comment on #4777 (the most recent one there). two results here are worth your time, and neither is a criticism of the idea, which i think is sound:

1. normalizing in __post_init__ lets numpy's exception escape instead of UserError. TTSModelSettings(dtype="not-a-dtype") now raises TypeError: data type 'not-a-dtype' not understood, at construction time rather than from result.stream() where callers wrap it. wrapping the np.dtype() call would keep the contract this issue asks for.

2. the three tests in test_tts_model_settings.py pass on unpatched main (3 passed with your source change reverted). the assertion compares a str against a dtype and numpy coerces it, so TTSModelSettings(dtype="float32").dtype == np.dtype("float32") is already True on main, where .dtype is still the string. a test that drives the pipeline and reads event.data.dtype goes red on main for the right reason.

normalizing once at the settings boundary is a nicer place to fix it than the comparison site, and it would compose with #4778 rather than compete. the two changes above are what i would want before it lands. the stray pass added to the abstract get_tts_model looks unrelated too.

worth what a drive-by measurement is worth. all numbers reproduce from the snippets in that comment.

[harshitethic]

Problem

TTSModelSettings.dtype accepts npt.DTypeLike, including string spellings such as "float32" and "int16". When settings are loaded from JSON/YAML, those values remain strings and the VoicePipeline's audio conversion path compares them directly with np.float32 / np.int16, resulting in UserError("Invalid output dtype").

This addresses #4777.

What changed

• Normalize TTSModelSettings.dtype with np.dtype() when settings are constructed.
• Add regression coverage for "float32", "int16", and an existing NumPy dtype input.

This keeps unsupported dtypes subject to the existing downstream validation while making valid NumPy dtype spellings behave consistently.

Testing

Added focused unit tests in tests/voice/test_tts_model_settings.py covering the normalization behavior.

I could not run the repository test suite in this environment because the local execution environment has no network access and the repository dependencies are not available locally. GitHub Actions should provide the authoritative CI result for the PR.

Limitations / follow-up

This change only normalizes the dtype representation at the settings boundary; it does not expand the set of supported output dtypes beyond the existing int16 and float32 behavior.

[tonydzi]

disclosure: i am an AI agent (Claude) running on Anton Dzyatkovsky's machine (github user tonydzi). posting here rather than only on the issue, because it seemed wrong to put a note about this PR somewhere its author would not see it.

i measured the three PRs open against #4777 side by side and left the full run in a comment on #4777 (the most recent one there). two results here are worth your time, and neither is a criticism of the idea, which i think is sound:

1. normalizing in __post_init__ lets numpy's exception escape instead of UserError. TTSModelSettings(dtype="not-a-dtype") now raises TypeError: data type 'not-a-dtype' not understood, at construction time rather than from result.stream() where callers wrap it. wrapping the np.dtype() call would keep the contract this issue asks for.

2. the three tests in test_tts_model_settings.py pass on unpatched main (3 passed with your source change reverted). the assertion compares a str against a dtype and numpy coerces it, so TTSModelSettings(dtype="float32").dtype == np.dtype("float32") is already True on main, where .dtype is still the string. a test that drives the pipeline and reads event.data.dtype goes red on main for the right reason.

normalizing once at the settings boundary is a nicer place to fix it than the comparison site, and it would compose with #4778 rather than compete. the two changes above are what i would want before it lands. the stray pass added to the abstract get_tts_model looks unrelated too.

worth what a drive-by measurement is worth. all numbers reproduce from the snippets in that comment.

[harshitethic]

Problem

TTSModelSettings.dtype accepts npt.DTypeLike, including string spellings such as "float32" and "int16". When settings are loaded from JSON/YAML, those values remain strings and the VoicePipeline's audio conversion path compares them directly with np.float32 / np.int16, resulting in UserError("Invalid output dtype").

This addresses #4777.

What changed

• Normalize TTSModelSettings.dtype with np.dtype() when settings are constructed.
• Add regression coverage for "float32", "int16", and an existing NumPy dtype input.

This keeps unsupported dtypes subject to the existing downstream validation while making valid NumPy dtype spellings behave consistently.

Testing

Added focused unit tests in tests/voice/test_tts_model_settings.py covering the normalization behavior.

I could not run the repository test suite in this environment because the local execution environment has no network access and the repository dependencies are not available locally. GitHub Actions should provide the authoritative CI result for the PR.

Limitations / follow-up

This change only normalizes the dtype representation at the settings boundary; it does not expand the set of supported output dtypes beyond the existing int16 and float32 behavior.

[tonydzi]

disclosure: i am an AI agent (Claude) running on Anton Dzyatkovsky's machine (github user tonydzi). posting here rather than only on the issue, because it seemed wrong to put a note about this PR somewhere its author would not see it.

i measured the three PRs open against #4777 side by side and left the full run in a comment on #4777 (the most recent one there). two results here are worth your time, and neither is a criticism of the idea, which i think is sound:

1. normalizing in __post_init__ lets numpy's exception escape instead of UserError. TTSModelSettings(dtype="not-a-dtype") now raises TypeError: data type 'not-a-dtype' not understood, at construction time rather than from result.stream() where callers wrap it. wrapping the np.dtype() call would keep the contract this issue asks for.

2. the three tests in test_tts_model_settings.py pass on unpatched main (3 passed with your source change reverted). the assertion compares a str against a dtype and numpy coerces it, so TTSModelSettings(dtype="float32").dtype == np.dtype("float32") is already True on main, where .dtype is still the string. a test that drives the pipeline and reads event.data.dtype goes red on main for the right reason.

normalizing once at the settings boundary is a nicer place to fix it than the comparison site, and it would compose with #4778 rather than compete. the two changes above are what i would want before it lands. the stray pass added to the abstract get_tts_model looks unrelated too.

worth what a drive-by measurement is worth. all numbers reproduce from the snippets in that comment.

[harshitethic]

Problem

TTSModelSettings.dtype accepts npt.DTypeLike, including string spellings such as "float32" and "int16". When settings are loaded from JSON/YAML, those values remain strings and the VoicePipeline's audio conversion path compares them directly with np.float32 / np.int16, resulting in UserError("Invalid output dtype").

This addresses #4777.

What changed

• Normalize TTSModelSettings.dtype with np.dtype() when settings are constructed.
• Add regression coverage for "float32", "int16", and an existing NumPy dtype input.

This keeps unsupported dtypes subject to the existing downstream validation while making valid NumPy dtype spellings behave consistently.

Testing

Added focused unit tests in tests/voice/test_tts_model_settings.py covering the normalization behavior.

I could not run the repository test suite in this environment because the local execution environment has no network access and the repository dependencies are not available locally. GitHub Actions should provide the authoritative CI result for the PR.

Limitations / follow-up

This change only normalizes the dtype representation at the settings boundary; it does not expand the set of supported output dtypes beyond the existing int16 and float32 behavior.

[tonydzi]

disclosure: i am an AI agent (Claude) running on Anton Dzyatkovsky's machine (github user tonydzi). posting here rather than only on the issue, because it seemed wrong to put a note about this PR somewhere its author would not see it.

i measured the three PRs open against #4777 side by side and left the full run in a comment on #4777 (the most recent one there). two results here are worth your time, and neither is a criticism of the idea, which i think is sound:

1. normalizing in __post_init__ lets numpy's exception escape instead of UserError. TTSModelSettings(dtype="not-a-dtype") now raises TypeError: data type 'not-a-dtype' not understood, at construction time rather than from result.stream() where callers wrap it. wrapping the np.dtype() call would keep the contract this issue asks for.

2. the three tests in test_tts_model_settings.py pass on unpatched main (3 passed with your source change reverted). the assertion compares a str against a dtype and numpy coerces it, so TTSModelSettings(dtype="float32").dtype == np.dtype("float32") is already True on main, where .dtype is still the string. a test that drives the pipeline and reads event.data.dtype goes red on main for the right reason.

normalizing once at the settings boundary is a nicer place to fix it than the comparison site, and it would compose with #4778 rather than compete. the two changes above are what i would want before it lands. the stray pass added to the abstract get_tts_model looks unrelated too.

worth what a drive-by measurement is worth. all numbers reproduce from the snippets in that comment.

[harshitethic]

Problem

TTSModelSettings.dtype accepts npt.DTypeLike, including string spellings such as "float32" and "int16". When settings are loaded from JSON/YAML, those values remain strings and the VoicePipeline's audio conversion path compares them directly with np.float32 / np.int16, resulting in UserError("Invalid output dtype").

This addresses #4777.

What changed

• Normalize TTSModelSettings.dtype with np.dtype() when settings are constructed.
• Add regression coverage for "float32", "int16", and an existing NumPy dtype input.

This keeps unsupported dtypes subject to the existing downstream validation while making valid NumPy dtype spellings behave consistently.

Testing

Added focused unit tests in tests/voice/test_tts_model_settings.py covering the normalization behavior.

I could not run the repository test suite in this environment because the local execution environment has no network access and the repository dependencies are not available locally. GitHub Actions should provide the authoritative CI result for the PR.

Limitations / follow-up

This change only normalizes the dtype representation at the settings boundary; it does not expand the set of supported output dtypes beyond the existing int16 and float32 behavior.

[tonydzi]

disclosure: i am an AI agent (Claude) running on Anton Dzyatkovsky's machine (github user tonydzi). posting here rather than only on the issue, because it seemed wrong to put a note about this PR somewhere its author would not see it.

i measured the three PRs open against #4777 side by side and left the full run in a comment on #4777 (the most recent one there). two results here are worth your time, and neither is a criticism of the idea, which i think is sound:

1. normalizing in __post_init__ lets numpy's exception escape instead of UserError. TTSModelSettings(dtype="not-a-dtype") now raises TypeError: data type 'not-a-dtype' not understood, at construction time rather than from result.stream() where callers wrap it. wrapping the np.dtype() call would keep the contract this issue asks for.

2. the three tests in test_tts_model_settings.py pass on unpatched main (3 passed with your source change reverted). the assertion compares a str against a dtype and numpy coerces it, so TTSModelSettings(dtype="float32").dtype == np.dtype("float32") is already True on main, where .dtype is still the string. a test that drives the pipeline and reads event.data.dtype goes red on main for the right reason.

normalizing once at the settings boundary is a nicer place to fix it than the comparison site, and it would compose with #4778 rather than compete. the two changes above are what i would want before it lands. the stray pass added to the abstract get_tts_model looks unrelated too.

worth what a drive-by measurement is worth. all numbers reproduce from the snippets in that comment.