![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(44.800000000000004, 28.000000000000004%, 14%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJS%3C/text%3E%3C/svg%3E)
Azure Speech in Foundry Tools
An Azure service that integrates speech processing into apps and services.
The correlated 6–7-second plateau and omitted PronunciationAssessment payload require a Microsoft support investigation; capture SDK logs and service request IDs from affected and unaffected calls while preserving the current reproducible workload.
What the results establish
-
ja-JPis supported for Pronunciation Assessment and is available in all speech-to-text regions, so this is not an unsupported-locale configuration. ^1^ - There is no currently documented Speech known issue matching
ja-JP, Japan East, Python SDK 1.50.0, a 6–7-second plateau, or missing Pronunciation Assessment blocks. ^2^ - The default S0 limit is 100 concurrent real-time speech-to-text and speech-translation requests combined. Three request starts per second does not itself show that this concurrency limit was reached; actual overlapping sessions must be measured. ^3^
-
BlockedCalls=0means no calls were recorded as exceeding a rate or quota limit.SuccessfulCallsrecords successful calls, whileTotalErrorsrecords 4xx/5xx responses; these metrics do not validate that an optional assessment object was present in a successful response. ^4^ -
SpeechServiceResponse_RecognitionLatencyMsis measured from the last contributing audio fragment received by the SDK until the final service result is received. It therefore includes the final-result path but does not isolate backend processing, queueing, or network delay. ^5^
Consequently, neither throttling nor a specific timeout can be inferred from the 6–7-second cluster. The open SDK report matching this exact configuration and symptom has not yet established a cause or workaround. ^6^
Capture an escalation-ready trace
Enable one process-wide SDK log, then record the service request ID, recognition latency, result reason, JSON presence, wall time, and UTC timestamp for every call:
import json, time
import azure.cognitiveservices.speech as speechsdk
speech_config.set_property(
speechsdk.PropertyId.Speech_LogFilename, "speech-sdk.log"
)
started = time.time()
result = recognizer.recognize_once()
props = result.properties
raw = props.get_property(
speechsdk.PropertyId.SpeechServiceResponse_JsonResult
)
request_id = props.get_property(
speechsdk.PropertyId.SpeechServiceResponse_RequestId
)
latency = props.get_property(
speechsdk.PropertyId.SpeechServiceResponse_RecognitionLatencyMs
)
payload = json.loads(raw) if raw else {}
print(request_id, latency, time.time() - started,
result.reason, "PronunciationAssessment" in raw)
Speech SDK logging is process-wide, so concurrent recognizers write interleaved entries to the same log; separate per-recognizer log files are not supported. ^7^
Provide Microsoft support with:
- The exact UTC test window and Speech resource region.
- Request IDs for several fast/scored and slow/unscored calls.
- The SDK log, minimal runnable reproducer, WAV file, Python/OS versions, and concurrency scheduler.
- Per-request start/end timestamps and peak in-flight request count.
- The raw JSON responses, with credentials and other sensitive data removed.
Supported mitigation to evaluate
If the application already knows the expected Japanese text—or can first obtain it using normal STT—run scripted assessment with that text instead of reference_text="". Microsoft documents that unscripted assessment uses a different STT model and recommends first obtaining reference text with Azure STT, then performing scripted assessment when accurate recognized text is required. ^8^
Treat this as an alternative scoring architecture, not a documented latency fix:
- Call standard STT for the audio.
- Use the resulting text as
reference_text. - Apply Pronunciation Assessment to a new recognition pass.
- Accept a result only when the expected assessment block exists.
- Retry missing-assessment results with bounded backoff and a strict retry limit; retain both request IDs.
The documentation confirms different result sets and models for scripted versus unscripted assessment, but it does not publish a ja-JP latency or reliability advantage for either mode. For this 1.75-second file, recognize_once() is appropriate: it returns after one utterance ends through silence detection, up to about 30 seconds. ^9^
Avoid changing segmentation timeouts or moving to continuous recognition solely to address this plateau; no supplied documentation ties either change to missing Pronunciation Assessment payloads for short prerecorded audio.
References
- Language and Voice Support for Azure Speech - Foundry Tools
- Azure Speech in Foundry Tools known issues - Foundry Tools
- Quotas and limits for Azure Speech
- Supported metrics for Microsoft.CognitiveServices/accounts
- Namespace Microsoft::CognitiveServices::Speech
- #3094 Pronunciation Assessment (ja-JP, unscripted): ~6.8 s latency plateau and missing PronunciationAssessment block at ~3 requests/second
- Enable logging in the Speech SDK (programming-language-python)
- Use pronunciation assessment (programming-language-objectivec)
- Recognizer Class-Methods