Is there an existing issue for this?
Did you read the "Reporting a bug" section on Contributing file?
Current Behavior
The AutoStopSilenceTimeout property in SpeechToTextOptions does not appear to work as expected on iOS device.
While the property can be set correctly and is recognized by the API, the speech recognition session does not automatically stop after the specified silence timeout.
The recognition session continues indefinitely (or until manually stopped), ignoring the configured silence timeout.
Expected Behavior
The recognition session should automatically stop after the configured silence timeout elapses.
Steps To Reproduce
- Configure
SpeechToTextOptions with AutoStopSilenceTimeout set (e.g. a few seconds)
- Start a speech recognition session
- Stop speaking and remain silent beyond the configured timeout
- Observe that the recognition session continues instead of stopping automatically
Link to public reproduction project repository
none
Environment
- .NET MAUI CommunityToolkit: 14.1.0
- OS:iOS 26.4
- .NET MAUI: 10.0.102
Anything else?
Additional Context
This behavior was observed while testing the feature introduced in version 14.1.0.
The implementation appears to be related to the following PR: #3111
I also performed a preliminary analysis using Claude, which suggests that the issue might be related to how silence detection is handled internally.
Claude Code analysis
After investigating the source code for the 14.1.0 tag of CommunityToolkit/Maui, the silence auto-stop logic on iOS appears to be implemented across two files (SharedSpeechToTextImplementation.macios.cs and SpeechToTextImplementation.ios.cs).
The current flow is:
InternalStartListeningAsync installs an audio tap using InstallTapOnBus, where RestartTimer() is called for every audio bufferRestartTimer() simply stops and restarts the silence timer- The timer is correctly initialized with
AutoStopSilenceTimeout when the value is less than TimeSpan.MaxValue
However, on iOS the audio tap continuously receives buffers from the microphone (~every 64 ms), even during silence (buffers contain near-zero samples but are still delivered).
Because of this, RestartTimer() is continuously triggered, resetting the silence timer before it can ever elapse.
Result: the auto-stop mechanism is effectively never triggered on iOS, regardless of the configured timeout.
Additionally, RestartTimer() is also invoked inside the recognitionTask callback, which is correct since it is triggered only when partial transcriptions are received (i.e., actual speech detected).
The issue appears to be the extra RestartTimer() call inside the audio tap, which should likely not be there.
On Android, the behavior works as expected because the implementation relies on the native recognizer (RecognizerIntent.ExtraSpeechInputCompleteSilenceLengthMillis), which uses built-in voice activity detection (VAD).
No existing issue seems to track this specific problem yet.
Is there an existing issue for this?
Did you read the "Reporting a bug" section on Contributing file?
Current Behavior
The
AutoStopSilenceTimeoutproperty inSpeechToTextOptionsdoes not appear to work as expected on iOS device.While the property can be set correctly and is recognized by the API, the speech recognition session does not automatically stop after the specified silence timeout.
The recognition session continues indefinitely (or until manually stopped), ignoring the configured silence timeout.
Expected Behavior
The recognition session should automatically stop after the configured silence timeout elapses.
Steps To Reproduce
SpeechToTextOptionswithAutoStopSilenceTimeoutset (e.g. a few seconds)Link to public reproduction project repository
none
Environment
Anything else?
Additional Context
This behavior was observed while testing the feature introduced in version
14.1.0.The implementation appears to be related to the following PR: #3111
I also performed a preliminary analysis using Claude, which suggests that the issue might be related to how silence detection is handled internally.
Claude Code analysis
After investigating the source code for the
14.1.0tag of CommunityToolkit/Maui, the silence auto-stop logic on iOS appears to be implemented across two files (SharedSpeechToTextImplementation.macios.csandSpeechToTextImplementation.ios.cs).The current flow is:
InternalStartListeningAsyncinstalls an audio tap usingInstallTapOnBus, whereRestartTimer()is called for every audio bufferRestartTimer()simply stops and restarts the silence timerAutoStopSilenceTimeoutwhen the value is less thanTimeSpan.MaxValueHowever, on iOS the audio tap continuously receives buffers from the microphone (~every 64 ms), even during silence (buffers contain near-zero samples but are still delivered).
Because of this,
RestartTimer()is continuously triggered, resetting the silence timer before it can ever elapse.Result: the auto-stop mechanism is effectively never triggered on iOS, regardless of the configured timeout.
Additionally,
RestartTimer()is also invoked inside therecognitionTaskcallback, which is correct since it is triggered only when partial transcriptions are received (i.e., actual speech detected).The issue appears to be the extra
RestartTimer()call inside the audio tap, which should likely not be there.On Android, the behavior works as expected because the implementation relies on the native recognizer (
RecognizerIntent.ExtraSpeechInputCompleteSilenceLengthMillis), which uses built-in voice activity detection (VAD).No existing issue seems to track this specific problem yet.