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

Hi Connor00712 :D & thx for join me at Q&A platform,

fact that you've reproduced this across multiple voices, regions, browsers, devices, and even direct REST requests is pretty significant. I'd be looking at a possible Speech TTS service-side quality regression rather than a Speech Studio playback issue.

The strongest evidence is that the artifacts are present in the downloaded audio itself. A successful HTTP response only tells us that the synthesis request completed. It doesn't guarantee that the generated audio is free of defects.

I'd run one additional test using uncompressed PCM/WAV output, preferably riff-24khz-16bit-mono-pcm, and inspect the resulting waveform in Audacity. Look for sudden amplitude changes, short sections of silence, clipping, or discontinuities at the exact positions where you hear the artifacts.

This helps distinguish problems introduced during audio encoding or playback from artifacts already present in the synthesized waveform. If the same type of defect occurs in uncompressed PCM, MP3 encoding becomes a much less likely explanation.

I'd also generate the exact same short Czech text several times using the same voice, region, and output format. Keep the original audio files and compare the affected timestamps. Neural synthesis isn't necessarily bit-for-bit deterministic, but repeated stuttering or dropouts aren't normal output variations.

The regional behavior is particularly interesting. If changing regions moves the artifacts to different positions without eliminating them, that could indicate an issue in the synthesis pipeline or model serving infrastructure. It doesn't prove a global regression, but it gives Microsoft a useful direction to investigate.

At this point, I'd open an Azure Speech technical support case and request investigation by the Speech TTS engineering team.

Include the affected voice names, regions, exact SSML or text input, output formats, UTC timestamps, Speech resource IDs, and any request or correlation IDs returned by the REST API. A short clean recording from before the problem started and a defective recording generated with identical settings would be especially valuable.

If possible, attach the original WAV files rather than recordings of the playback. That lets engineering inspect the actual audio samples and compare them against the synthesis service's output. Keep subscription keys and authorization headers out of any shared diagnostics.

I wouldn't spend more time changing browsers or creating new Speech resources. You've already demonstrated that those changes don't resolve the issue.

Also, the absence of a Service Health incident doesn't rule out a synthesis quality regression. Availability monitoring and audio quality monitoring are different things, and a service can return successful responses while producing degraded output.

Given the number of independent reproductions, this deserves a backend investigation rather than another round of client-side troubleshooting.

rgds,

Alex

p.s. if my answer is help - pls mark it as an answer

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