-
Notifications
You must be signed in to change notification settings - Fork 4.7k
fix(voice): accept every NumPy spelling of a supported TTS dtype #4778
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
Nikhils-G
wants to merge
6
commits into
openai:main
Choose a base branch
from
Nikhils-G:fix/voice-tts-dtype-spellings
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+112
−2
Open
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
cf79d1d
fix(voice): accept every NumPy spelling of a supported TTS dtype
Nikhils-G 2cb8c3b
Keep the SDK error for dtypes NumPy cannot parse
Nikhils-G 0834d11
Pin the byte-order rejection so it is a decision, not an accident
Nikhils-G c189427
Derive the byte-order case from the running host
Nikhils-G 620820d
Say which dtype case is coverage and which is a pin
Nikhils-G 8d07ccf
Defend the dtype contract and keep the NumPy cause
Nikhils-G File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On a big-endian host, the newly supported
"int16"spelling resolves equal to nativenp.int16, so this branch returnsnp_arrayeven though line 107 decoded the incoming bytes in native big-endian order. The repository’s PCM helper explicitly produces little-endian bytes withdtype="<i2"(src/agents/voice/testing.py:403-405), so nonzero samples are byte-swapped for this newly accepted configuration. Unlike the earlier test-portability comment, this is fresh production-path evidence: decode the PCM as little-endian and convert the emitted array to the requested native dtype.AGENTS.md reference: AGENTS.md:L164-L164
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not think this one belongs to this patch, and the diff shows why.
The decode is untouched here —
np.frombuffer(combined_buffer, dtype=np.int16)appears as context in the diff, not as a changed line. Onmainthose two lines already read:Both
np.int16andnp.dtype("int16")satisfy that comparison today, so the branch is already reachable on a supported path and already returns natively decoded samples. This patch adds the string spelling to the same branch; it does not change what the branch does, or how the bytes were read before it.On the citation:
pcm16_sampleslives inagents/voice/testing.pyand its docstring says it produces native little-endian bytes for fixtures. The production path takes its bytes from the TTS model rather than from that helper.The underlying point is fair, though. Decoding provider PCM16 as native rather than little-endian is wrong on a big-endian host, and it is wrong there for
np.int16onmainright now. Correcting it means reading as"<i2"and converting on output, which changes what existing callers receive on those hosts — a different change with a different rationale. By the AGENTS.md line cited above, that is a pre-existing condition rather than one this patch introduces or worsens.Happy to raise it as its own issue, or to fold it in here if a maintainer would rather have it in one go.