From Voice Gallery to Running Code: The Text to Speech Authoring Path

What this slice covers

Most speech features in Foundry can be exercised twice: once by clicking, once by writing code. Text to speech is the clearest example, and the exam cares about the journey between the two. A candidate who only ever ran the playground cannot answer questions about what an application must configure; a candidate who only ever read SDK samples cannot explain how a designer picks a voice. This note follows the path from browsing voices in the portal to a running program, and points out what changes at each step.

Step one: hearing voices before you commit

The portal exposes a voice gallery — a browsable catalogue of prebuilt synthetic voices that you can filter and audition. You type sample text, press play, and hear the result immediately. Nothing is deployed, no code exists yet, and no audio file is produced for you to ship.

This step exists because voice selection is a product decision, not an engineering one. The difference between two voices reading the same sentence is a difference in how your product feels, and that is not a judgement anyone should make from a name in a table. Expect exam scenarios where the right answer is audition voices in the portal precisely because the question is about choosing rather than building.

Alongside the gallery, the playground exposes tuning controls for the selected voice. Treat these as a preview of what you will later set in code or in markup, not as a separate feature.

Step two: the handoff to code

The crucial affordance is that the portal will generate a code sample for the configuration you just auditioned, in the language you prefer. This is the intended bridge, and it removes the most error-prone part of getting started: matching the voice you liked to the exact identifier your application must send.

Understanding what that generated sample contains is worth more than memorising it. It always has three parts. First, a speech configuration that names your endpoint and carries your credential. Second, an audio output configuration that says where the sound should go. Third, a synthesizer object built from those two, given a string to speak. Every text to speech program you will ever write in this stack has that skeleton.

Step three: what the application must supply that the portal supplied for you

In the portal, your identity and the resource were already resolved. In code, both become your responsibility, and this is where beginners lose time.

You need a Speech-capable Foundry resource and its endpoint. You need a credential. The quickstart demonstrates reading a key and endpoint from environment variables, which keeps secrets out of source files, and it is explicit that this is a getting-started convenience rather than a production pattern. For anything running in Azure, Microsoft's guidance is to authenticate with Microsoft Entra ID and a managed identity so that no key exists in your application at all. Where keys genuinely must be used, they belong in Key Vault with rotation and access control around them.

There is a small operational trap in the environment-variable approach that catches almost everyone once: a process that was already running does not see a variable you set afterwards. If you set the variables and the sample still fails, restart the terminal — and the editor, if you launched from one.

How the pieces relate

It helps to see the three configurations as answers to three separate questions, because they change independently.

Which service, as whom? — the speech configuration. This changes when you move between resources or environments.

Which voice? — also carried on the speech configuration, as a voice name. This changes when the product changes its mind about tone.

Where does the audio go? — the audio output configuration. This changes when you move from a desktop demo that plays through the speaker to a service that must return bytes over HTTP.

Learners who blur the second and third question write code that plays audio on a server nobody is sitting at. Keeping them separate makes the fix obvious.

Mistakes people make

The first mistake is treating the playground as the deliverable. Clicking play proves the voice sounds right; it proves nothing about latency, cost, or how your application handles a failure.

The second is copying a generated sample without reading the credential section, then hard-coding a key to make it run. That habit is exactly what the documentation warns against, and it is the sort of thing an exam scenario will test by asking which authentication approach is recommended for an application running in Azure.

The third is assuming the portal's tuning controls are the only expressive control available. They are the shallow end. Finer control over how a voice delivers text — emphasis, pauses, pace, switching voices mid-passage — comes from the speech synthesis markup language, which you send instead of plain text. Knowing that this escalation path exists, and that it is markup rather than a different service, is the level of understanding this exam expects.