Recognizing Speech with Azure Speech in Foundry

Speech to text is the Foundry Tools capability that turns spoken audio into written text. For this exam you are not asked to build a recognizer from scratch, but you are asked to know what the service does, which setting controls which behaviour, and where the edges of a simple call are. This note follows the same path the official quickstart follows: try it in the portal first, then understand the shape of a real call.

Two front doors into the same service

The quickest way in is the Foundry portal. You open the speech to text feature page in the playground, optionally adjust settings such as the task, the language and the profanity policy, upload an audio file, and start the run. The transcription appears in a transcript tab, and the raw API response is available in a JSON tab beside it. A code tab then hands you a working sample for your own application.

That last detail is the point worth holding: the playground is not a separate product. It is a front end over the same service your code will call, which is why the portal can hand you code that does what you just did by clicking. The second door is the Speech SDK, available for languages including Python, C#, Java, JavaScript, C++, Go and Swift, plus a REST API for short audio. The concepts are identical across all of them; only the spelling changes.

The resource and the credential story

Before any of this works you provision a Speech resource of the Foundry kind from the Azure portal, then collect its key and its region or endpoint from the resource's keys page. The quickstart stores those in environment variables — SPEECH_KEY plus either SPEECH_REGION or ENDPOINT — and reads them from code.

Notice that the documentation immediately qualifies its own approach. Environment variables are shown for convenience, and the guidance is that production should use something more secure: Microsoft Entra ID authentication with managed identities, so that credentials are not stored alongside applications running in the cloud. If you do use keys, they belong in Azure Key Vault, rotated regularly and access-controlled, never pasted into source and never posted publicly. Expect this responsible-handling framing to show up in questions that look like they are about speech but are really about credentials.

The anatomy of a recognition call

Three objects do the work. A speech configuration carries your credentials and your language choice. An audio configuration says where the sound comes from — the default microphone, or a file name if you are reading from disk. A recognizer joins the two and performs the recognition.

The single-shot operation is the one to understand first, because its limits are also its teaching points. It handles one utterance of up to half a minute, and it stops either when that ceiling is reached or as soon as silence is detected. Two conditions end it, not one. For longer audio, or multi-lingual conversations, you move to continuous recognition rather than calling the single-shot operation repeatedly. For files, batch transcription handles audio asynchronously, and a fast transcription API exists for quickly transcribing files.

Reading the result instead of assuming success

A recognition result carries a reason, and mature code branches on it. The first outcome is that speech was recognised, and you read the text off the result. The second is NoMatch: the service ran but found nothing it could transcribe, which is an outcome rather than an error. The third is Canceled, and when the cancellation reason is an error you inspect the error details, which is where a wrong key or endpoint surfaces.

The three-way split is worth memorising as a concept: success, no match, cancelled. A learner who treats "no text came back" as automatically a failure has missed the distinction the API is drawing.

Language, accuracy, and the audio itself

The recognition language is set on the speech configuration, for example by replacing en-US with es-ES for Spanish (Spain). Leave the language unset and en-US is what you get — a small default with an outsized effect on results. When you do not know the language in advance, language identification compares the audio against a list of supported languages, either at the start or continuously.

Several other levers appear in the playground's advanced options. A phrase list feeds the recogniser terms you already expect to hear — people's names, particular places — so it favours them over acoustically similar alternatives; the values are separated by commas or semicolons. Speaker diarization works out who spoke when, attributing each stretch of transcript to a distinct participant in the conversation. A custom endpoint points at a model deployed from custom speech instead of Microsoft's baseline model. Output format chooses between simple output, with display format and timestamps, and detailed output, which adds lexical, ITN and masked ITN forms plus N-best lists.

Finally, respect the audio. The samples use .wav files, and compressed formats such as MP4 require GStreamer with a pull or push input stream. Format, length and language are the three things that most often explain a disappointing transcript before the model is at fault.