Azure Speech Ingestion client not processing audio input

Hi PCS Dev,

Thank you for bringing this to our attention. We are currently checking the details and working on resolving the issue. We’ll update you as soon as we have more information.

Thankyou!

Any further details Anshika?

Hello @PCS Dev

Thank you for the detailed information.

Based on your description, the behavior indicates that the ingestion pipeline is currently not picking up new blobs from the audio-input container, which is why files remain idle and no transcription is triggered. This typically points to an issue with the ingestion client (Function App / trigger configuration) rather than the Speech service itself.

Key areas to validate

1. Function App trigger status Please navigate to your Function App → Functions and check the blob-triggered function (e.g., IngestionTrigger).

• Verify the function is present and enabled
• Check the Monitor/Logs tab to confirm whether any BlobCreated events are being triggered

If there is no activity, it indicates the trigger is not firing.

2. Event Grid / Blob trigger configuration Depending on your deployment, ingestion relies on either Blob trigger bindings or Event Grid.

• Go to Storage Account → Events
• Ensure there is an active subscription for Microsoft.Storage.BlobCreated pointing to your Function App

If this is missing or misconfigured, uploaded files will not trigger processing.

3. Function App configuration settings After upgrading from Free to Paid tier, it is important to revalidate configuration:

• AzureWebJobsStorage → should point to the correct storage account
• SpeechKey / SPEECH_SERVICE_KEY → must be the valid key from the paid Speech resource
• SpeechRegion → must match the Speech resource region

Any mismatch here can prevent processing without generating visible errors.

4. Verify Function App is running Ensure the Function App status is Running. A restart of the Function App is also recommended to reinitialize triggers after configuration changes.

5. Check Application Insights logs Even if no logs are visible at storage level:

• Go to Function App → Application Insights → Logs
• Look for:
  • Trigger failures
  • Binding errors
  • Authentication issues

6. Network / access configuration If you are using VNet or firewall restrictions:

• Ensure the Function App can access the Storage Account
• Ensure outbound access to the Speech endpoint is allowed

7. File validation

• Confirm files are placed in the correct container (audio-input)
• Ensure WAV files are in supported PCM format

8. Manual validation test As a quick isolation step, you may try calling the Speech batch transcription API directly (via REST/CLI) using the same file.

• If this fails → configuration/Speech issue
• If this succeeds → ingestion pipeline issue

Please refer this

Ingestion Client (ARM template, Event Grid, Functions) https://docs.microsoft.com/azure/ai-services/speech-service/ingestion-client

Troubleshoot Speech Services deployment issues (regions, private link/VNet) https://docs.microsoft.com/azure/cognitive-services/speech-service/speech-services-private-link?tabs=portal

HTTP 408 Request Timeout (no audio / network issues) https://docs.microsoft.com/azure/cognitive-services/speech-service/troubleshooting#error-http-408-request-timeout

I Hope this helps. Do let me know if you have any further queries.

Thank you!

In application insights, I was able to find this exception.

C:\Program Files (x86)\dotnet\dotnet.exe exited with code -532462766 (0xE0434352) Unhandled exception. System.ArgumentException: Keyword not supported: '@microsoft.keyvault(vaultname'., at Microsoft.EntityFrameworkCore.Storage.RelationalConnection.Open(Boolean errorsExpected)

Microsoft.Azure.WebJobs.Script.Workers.WorkerProcessExitException:

at Microsoft.Azure.WebJobs.Script.Workers.WorkerProcess.ThrowIfExitError (Microsoft.Azure.WebJobs.Script.Grpc, Version=4.1048.0.0, Culture=neutral, PublicKeyToken=null: /_/src/WebJobs.Script.Grpc/ProcessManagement/WorkerProcess.cs:276)

at Microsoft.Azure.WebJobs.Script.Workers.WorkerProcess.OnProcessExited (Microsoft.Azure.WebJobs.Script.Grpc, Version=4.1048.0.0, Culture=neutral, PublicKeyToken=null: /_/src/WebJobs.Script.Grpc/ProcessManagement/WorkerProcess.cs:231)

at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)

at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)

at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)

at System.Runtime.CompilerServices.TaskAwaiter.GetResult (System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)

at Microsoft.Azure.WebJobs.Script.Grpc.GrpcWorkerChannel+<StartWorkerProcessAsync>d__74.MoveNext (Microsoft.Azure.WebJobs.Script.Grpc, Version=4.1048.0.0, Culture=neutral, PublicKeyToken=null: /_/src/WebJobs.Script.Grpc/Channel/GrpcWorkerChannel.cs:393)

Inner exception System.Exception handled at Microsoft.Azure.WebJobs.Script.Workers.WorkerProcess.ThrowIfExitError:

So I went and looked at the environment variables and it led me to review the SQL settings.

The SQL database piece of the ARM template had failed, so I set the "UseDatabase" variable to false and upon restarting the function app it seems to work now.

Hi @PCS Dev

Thank you for sharing the detailed findings and the exception from Application Insights.

From the error “Keyword not supported: '@microsoft.keyvault(vaultname'”

this indicates that the Function App was attempting to read a Key Vault reference as a plain connection string, which is not supported by the underlying SQL/EF configuration. As a result, the worker process was crashing during startup, preventing the ingestion pipeline from initializing which is why no files were being processed from the audio-input container.

What resolved the issue

Setting UseDatabase = false effectively bypassed the SQL dependency, allowing the Function App to start successfully and resume processing. This confirms that:

• The ingestion pipeline itself is healthy
• The root cause was isolated to the SQL/Key Vault configuration

Root cause summary

The ARM template deployment for the SQL component did not complete successfully

The application settings still referenced:

• A SQL connection string
• Potentially via Key Vault reference syntax (@Microsoft.KeyVault(...))

The Function runtime attempted to use this value directly, causing a startup failure

Recommendations

If you plan to enable the database feature again, here are the key things to validate:

Correct Key Vault reference usage

Ensure the setting uses proper format:

@Microsoft.KeyVault(SecretUri=https://<vault-name>.vault.azure.net/secrets/<secret-name>/)

Avoid partial or malformed references

Managed Identity access

Ensure the Function App’s Managed Identity has Get permission on Key Vault secrets

Application setting resolution

In the Function App → Configuration, confirm the value is resolved (not showing as raw @Microsoft.KeyVault(...) at runtime)

SQL connection string format

Ensure the secret contains a valid SQL connection string (not just a password or partial value)

Redeploy SQL resources

If the ARM deployment failed earlier, consider re-deploying or validating the SQL resources

Your current workaround (UseDatabase = false) is a valid approach if database persistence is not required for your scenario. Otherwise, correcting the Key Vault + SQL configuration should allow you to re-enable it safely.

Thank you!