An Azure service that integrates speech processing into apps and services.
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").
- 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