Intermittent audio artifacts in Azure Speech TTS output across voices, formats, and regions

Connor00712 :D 0 Reputation points
2026-10-12T20:17:20.24+00:00

I use Azure Speech Studio at speech.microsoft.com to synthesize Czech speech.

The problem started suddenly. One generation sounded clean. About 30 minutes later, I regenerated the same text with the same settings, and the new output had noticeable volume changes and brief stuttering/dropouts. The issue has continued since then.

The artifacts are audible both in Speech Studio and in the downloaded audio file. Changing the Azure region changes where the artifacts occur in the audio, but has not eliminated them.

I have reproduced the issue:

  • with multiple voices;
  • in MP3 (48 kHz) and WAV;
  • in different browsers, on different devices and networks;
  • with Speech resources in several regions, including an older resource and a newly created one;
  • on both Free and paid Speech resources;
  • through a direct REST API request as well as through Speech Studio.

The REST request completes successfully and returns an audio file, but the artifact is still present in that file. Azure’s resource diagnostics report that the resource is available and show no active Service Health incident. Some diagnostic summaries mention occasional blocked or client requests, but the audio artifact also occurs in successful REST responses.

Has anyone seen a similar quality regression in Azure’s standard neural TTS voices? Is there a way to determine whether these artifacts are present in the audio returned by the synthesis service, and what request details would help Microsoft investigate?

Azure Speech in Foundry Tools
0 comments No comments

1 answer

Sort by: Most helpful
  1. Jerald Felix 18,840 Reputation points Volunteer Moderator
    2026-10-13T02:01:29.28+00:00

    Hello Connor00712 :D,

    Greetings! Thanks for raising this question in the Q&A forum.

    You have already done most of the isolation work. The artifacts appear in Speech Studio, in downloaded files, and in a direct REST response, across browsers, devices, networks, voices, formats (MP3 48 kHz and WAV), regions, and Free and paid resources. That rules out your browser, your network, your playback device and a single resource or region. The most likely explanation is a service-side regression in the synthesis output for that voice or locale, which is why a Microsoft engineer needs to look at it with request-level details. I can't confirm the cause from here, and I'm not aware of any user-side setting that would fix a defect that is already present in the returned audio file.

    To confirm the artifact comes from the service and to give Microsoft what they need, please follow these steps.

    Capture a minimal reproducible sample. Pick one voice (for example a Czech neural voice such as cs-CZ-VlastaNeural or cs-CZ-AntoninNeural) and a short text of a few sentences that reproduces the problem. Keep the exact SSML or text, the voice name, the output format and the region. Save one "good" and one "bad" audio file generated from the same input if you still have a clean one.

    Check the raw file outside any player. Download the file and open it in an audio editor such as Audacity and look at the waveform. Dropouts and sudden volume jumps show clearly as gaps or amplitude changes, which proves the defect is in the returned audio and not in playback. Also try the plain WAV format without MP3 compression, for example riff-24khz-16bit-mono-pcm, to rule out an encoding issue.

    Test with the Speech SDK and record the request ID. Using the SDK lets you capture a ResultId for each synthesis. A Python example:

    result = synthesizer.speak_text_async(text).get()
    print(result.result_id)

    You can also enable SDK logging with speech_config.set_property(speechsdk.PropertyId.Speech_LogFilename, "speech-sdk.log").

    1. If you use REST, set a connection ID header. Add X-ConnectionId: <guid without hyphens> to the request and record it, together with the date, time and timezone of the request. The REST call looks like this:

    curl -X POST "https://<region>.tts.speech.microsoft.com/cognitiveservices/v1" -H "Ocp-Apim-Subscription-Key: <key>" -H "Content-Type: application/ssml+xml" -H "X-Microsoft-OutputFormat: riff-24khz-16bit-mono-pcm" -H "X-ConnectionId: <guid>" -d @request.ssml -o output.wav

    Test a few variations to narrow it down. Try the same text with a non-Czech voice, such as an en-US neural voice, and try a different Czech voice. If only Czech voices are affected, that points to a locale-specific model or deployment problem. Also try removing any <prosody> volume settings from your SSML, since an incorrectly formatted volume value (for example a percentage where an absolute value was intended) can cause large level shifts, though it would not explain dropouts on its own.

    Open an Azure Support request. Since the Q&A forum cannot access your resource, please raise a support ticket under Azure AI Speech, with the issue type "Text to speech". Include the subscription ID, resource names and regions, the voice names, the output formats, the request IDs or connection IDs, the exact UTC time of the failures, the good and bad audio samples, and the SDK log if you have one. Mention that Service Health shows no incident, and that the problem reproduces across regions and across Free and paid resources, as this helps the engineers prioritise it.

    If this answer helps you kindly accept the answer which will help others who have similar questions.

    Best Regards,
    Jerald Felix

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.