Synthesizing Speech: Voices, Locales and Output in Foundry

Text to speech is the mirror image of recognition. Instead of turning sound into text, Azure Speech in Foundry Tools takes text you supply and renders it as a human-sounding voice, which you can play through a speaker, write to a file, or capture as raw bytes for your own processing. The service is the same resource you use for recognition, so almost everything you learned about keys, regions and credentials carries straight across. What is genuinely new here is the voice: how you name one, what it can and cannot speak, and what happens when you ask for something it cannot do.

Trying it before coding it

The Foundry portal gives you a text to speech feature page that opens in a playground. You pick a prebuilt voice from a dropdown, optionally nudge it with the provider's parameter sliders, type sample text, and play the result. A voice gallery lets you browse and preview voices, filtering by keyword or by supported language, and a view-code option produces an SDK sample in your language of choice.

This is the right order of operations for a learner. Hearing three voices read the same sentence teaches you more about what "voice selection" means than any parameter table, and the gallery is also where you discover that a voice is a specific named asset rather than a generic setting like "female" or "fast".

The resource and the credentials

You provision a Speech resource of the Foundry kind from the Azure portal and collect its key plus region or endpoint. The quickstart puts these in the SPEECH_KEY and SPEECH_REGION or ENDPOINT environment variables and reads them from code, while telling you plainly that production deserves better: Entra ID authentication with managed identities, so credentials are not stored with cloud-hosted applications. Keys, if used, belong in Key Vault with rotation and access restrictions. This is the same guidance the speech to text quickstart gives, because it is the same resource.

The anatomy of a synthesis call

Three objects again. A speech configuration holds credentials and, critically, the voice name. An audio output configuration says where the audio goes. A synthesizer joins them and speaks the text.

The audio output configuration is more interesting than it first looks, because it has three meaningful settings. Point it at the default speaker and the audio plays immediately. Give it a file name and the audio is written to that file instead. Omit it entirely and no playback happens at all; instead you read the audio bytes off the result, which is what you want for streaming or format conversion. Choosing among these three is a design decision, not a detail.

The result carries a reason, exactly as recognition does. A completed synthesis is one outcome; cancellation is another, and an error cancellation exposes error details where a bad key or endpoint shows up.

Voice names are structured, not arbitrary

A voice name follows a three-part pattern: a locale, a voice name, and a voice type, written as locale-VoiceName:VoiceType. The locale tells you which language and region the voice belongs to natively, such as en-US for US English or es-ES for Spanish. The voice name is that voice's unique identifier — Ava or Andrew, for instance. The voice type indicates the underlying technology, for example an HD neural type or a multilingual type.

Reading a name such as en-US-Ava:DragonHDLatestNeural as three fields rather than one opaque string is a genuinely useful skill, because it tells you at a glance what language the voice belongs to and what class of voice it is. You find available voices three ways: browse the gallery to preview them by ear, consult the supported-voices list, or call the voice list API to retrieve them programmatically. Voices from OpenAI are available here too, and you swap one in simply by changing the name string.

The multilingual rule and its silent failure

Here is the subtlety most worth carrying into the exam. Neural voices are multilingual: each is fluent in its own language and in English. If you feed English text to a Spanish voice, you get English spoken with a Spanish accent — the voice does not refuse, and it does not translate. Translation is a different capability entirely; changing the voice changes the accent, not the words.

The failure mode on the other side is quieter. If the voice cannot speak the language of the text you sent, the service produces no synthesized audio at all. Nothing is mistranslated and nothing is approximated; you simply get silence. A learner debugging "why is there no sound" should check the pairing of voice and input language before suspecting the speaker, the file path or the key.

When plain text is not enough

The quickstart's operation synthesizes a short block of text with default delivery. When you need finer control — voice styles, prosody, pacing — you move to Speech Synthesis Markup Language, an XML format in which you wrap the text in speak and voice elements and name the voice as an attribute. The REST API works this way natively, posting SSML with an output-format header that selects the audio encoding. For long-form content there is a separate batch synthesis API rather than one enormous synchronous call.