OpenAI TTS alternative — handling the complete audio file response

Does EasyVoice support streaming/chunked TTS responses?

No. EasyVoice does not currently offer a streaming/chunked TTS endpoint. The endpoint at https://easyvoice.ae/api/v1/audio/speech buffers the complete audio file server-side and returns it in one HTTP response. The response body contains the complete MP3 or WAV file — there is no Transfer-Encoding: chunked header, no progressive byte delivery, and no ability to begin playback before synthesis is complete.

This differs from OpenAI's audio.speech.create, which does use HTTP chunked transfer-encoding to begin delivering audio bytes before synthesis finishes. If progressive streaming (first-byte before synthesis completes) is a hard requirement for your use case, EasyVoice's current endpoint does not satisfy it.

For the dominant TTS use cases — narration, chatbot responses, IVR prompts, accessibility read-aloud, content audio versions — the Kokoro synthesis speed (~1.1 ms/char on GPU) means the full-file response typically arrives in a few seconds for standard inputs. If full-file latency is acceptable for your application, EasyVoice's flat $9.99/mo plan covers all volumes.

Fetching the complete audio file in JavaScript

In JavaScript (Node.js 18+ or browser), use fetch with await res.arrayBuffer() to receive the complete audio file. The response body contains all audio bytes — call arrayBuffer() once and you have the complete file, ready to write to disk or create a Blob URL for browser playback.

In Node.js, write the buffer to a file with Buffer.from(await res.arrayBuffer()) and fs.writeFileSync. In the browser, create a Blob from the ArrayBuffer and use URL.createObjectURL to set as the src for an Audio element. The pattern is the same as handling any other binary HTTP response — no special streaming configuration needed.

Fetching the complete audio file in Python

In Python, use requests.post() without stream=True — the default behavior buffers the full response in memory, which is correct for a complete-file response. Access the audio bytes via res.content (a bytes object containing the complete file) and write to a file with f.write(res.content).

For asynchronous Python (asyncio / httpx), use httpx.AsyncClient and await response.aread() to get the complete response body. Both patterns receive the complete audio file in one call — there is no iteration or chunk accumulation needed.

Which response_format should I use?

EasyVoice supports mp3 (default) and wav. MP3 is the right choice for web playback, mobile apps, and any context where file size matters — at 128 kbps, a 60-second narration is approximately 1 MB. MP3 is directly playable in all major browsers and media players without additional libraries.

WAV (raw PCM) is the right choice for downstream audio processing pipelines — mixing into a podcast track, applying effects in Audacity, importing into a DAW. WAV files are uncompressed: a 60-second WAV is approximately 10 MB. Use wav when the downstream consumer is an audio processing library, not an end-user media player.

When EasyVoice is and isn't the right fit

EasyVoice is the right fit if your TTS use case can accept a full-file response with a few seconds of synthesis latency — narration, content audio versions, podcast intros, chatbot responses where the answer is computed before the audio starts, accessibility read-aloud, IVR prompts. At $9.99/mo flat with no per-character billing, it covers all volumes.

EasyVoice is not the right fit if your application requires progressive audio — bytes arriving at the client before synthesis is complete — for example a voice chatbot where users perceive the first word before the sentence is finished. OpenAI's audio.speech.create's chunked transfer-encoding satisfies that requirement; EasyVoice's current endpoint does not.