/v1/speech/stream is declared as an empty JSON 200, so no StreamAsStreamAsync is generated for the streaming TTS endpoint

Problem

src/libs/Murf/openapi.json declares POST /v1/speech/stream (operationId stream, "Stream Speech") with a 200 body of

"application/json": { "schema": { "$ref": "#/components/schemas/text_to_speech_stream_Response_200" } }

where text_to_speech_stream_Response_200 is { "type": "object", "properties": {}, "description": "Empty response body" }.

The real endpoint answers with chunked audio bytes (the whole point of the operation), so the generated SubpackageTextToSpeechClient.StreamAsync / StreamAsResponseAsync model an empty JSON object, and the package exposes no …AsStreamAsync for the one operation that streams. A consumer that wants first-audio latency from Murf has to bypass the SDK with a raw HttpClient today.

Fix

Declare the 200 as binary, e.g.

"200": { "content": { "audio/*": { "schema": { "type": "string", "format": "binary" } } } }

(or application/octet-stream), so AutoSDK emits StreamAsStreamAsync returning the response stream the same way Rime.TextToSpeechClient.CreateTtsAsStreamAsync, PlayHT.TextToSpeechClient.StreamSpeechAsStreamAsync and Cartesia.TtsClient.TtsBytesAsStreamAsync do.

Found while auditing which tryAGI TTS SDKs can feed a PCM streaming sink (HavenDV/Advantage, 2026-09-15).

Start in src/libs/Murf/openapi.json at POST /v1/speech/stream and compare its response declaration with the streaming TTS operations referenced in the issue. Regenerate or inspect the SDK and verify that StreamAsStreamAsync is emitted and exposes the endpoint's streamed audio response instead of an empty JSON object.