What problem does this solve?
When Only read dialogues is enabled, separate dialogue lines from the same message are played immediately one after another.
Because the TTS sequence currently starts the next generated clip as soon as the previous clip ends, conversations with multiple dialogue lines can sound unnaturally continuous.
Proposed solution
Add a persisted global TTS preference that inserts a configurable pause between distinct dialogue utterances when Only read dialogues is enabled.
Suggested behavior:
- Default pause:
300 ms
- Allowed range:
0–1500 ms
- Slider step:
50 ms
- Apply the pause only between distinct dialogue utterances.
- Do not pause between internal chunks belonging to the same long utterance.
- Do not pause after the final utterance.
- Preserve existing full-message playback when Only read dialogues is disabled.
- Support both progressive and non-progressive sequence playback.
- Allow playback to be stopped while waiting during a pause.
Alternatives considered
A fixed hard-coded pause would improve pacing, but it would not suit every voice or user preference. A configurable delay also allows users to select 0 ms to preserve immediate playback.
Adding a delay after every generated TTS request was also considered, but that would incorrectly introduce pauses between chunks of the same long dialogue line.
Additional context
The existing sequence-based TTS flow already creates individual voice requests and plays them through speakSequence() for both manual playback and autoplay. The pause can therefore be represented as playback metadata on the final chunk of each non-final dialogue utterance without changing generated audio or its cache identity.
Template check
What problem does this solve?
When Only read dialogues is enabled, separate dialogue lines from the same message are played immediately one after another.
Because the TTS sequence currently starts the next generated clip as soon as the previous clip ends, conversations with multiple dialogue lines can sound unnaturally continuous.
Proposed solution
Add a persisted global TTS preference that inserts a configurable pause between distinct dialogue utterances when Only read dialogues is enabled.
Suggested behavior:
300 ms0–1500 ms50 msAlternatives considered
A fixed hard-coded pause would improve pacing, but it would not suit every voice or user preference. A configurable delay also allows users to select
0 msto preserve immediate playback.Adding a delay after every generated TTS request was also considered, but that would incorrectly introduce pauses between chunks of the same long dialogue line.
Additional context
The existing sequence-based TTS flow already creates individual voice requests and plays them through
speakSequence()for both manual playback and autoplay. The pause can therefore be represented as playback metadata on the final chunk of each non-final dialogue utterance without changing generated audio or its cache identity.Template check