Re: [Emacspeak] Any solutions for the queuing issue in Swiftmac?

[Parham Doustdar <parham90@xxxxxxxxx>]

Hi,
Wow, thanks a lot for doing the work on this. Yes, since you don’t have a development set up, I’d definitely email Robert with the patch, maybe it’d be faster for him to review a patch than to create it himself.
I’d love your diff in the meantime if possible. I can apply it to my version as a bandage while I wait.
Thanks,
parham

> On 7 Sep 2026, at 22:00, Andrew Leland <al.list@xxxxxxxxxxxx> wrote:
> 
> Hey Parham,
> 
>> I’m using Emacspeak with Swiftmac and I notice that in longer lines, there seems to be a queueing issue, where things get spoken out of order. I was wondering if anyone has found a solution for this, or has a patch?
> 
> Yes — I hit exactly this, and it almost made emacspeak unusable for me, as I'm not a coder and use emacs mostly for org, writing, and notmuch, and so most of my emacspeak travels involved very long lines of prose. I ended up working through the SwiftMac source with an AI assistant (Claude, particularly earlier this summer when Fable was free), which did the actual diagnosis and wrote the fix, which I'm plagiarizing here. I was on 4.3.6 (robertmeta/swiftmac). I feel ambivalent sending this because as a nontechnical vibecoder I don't fully understand what I'm saying here or even if this is accurate. But since I shared your problem and the solution worked, I will swallow my pride about ventriloquizing an LLM on a FOSS listserv and continue. There turned out to be two things going on:
> 
> 1. The stop/interrupt path never flushes the pending text queue. SwiftMac queues text you send (q) and dispatches it (d) separately. When speech is stopped, the stop routine resets the audio player and clears the in-memory chunk list, but it never clears the pending command queue — so any text that was queued-but-not-yet-dispatched just sits there and gets spoken by the next dispatch, from the wrong place. (There's even a clearPendingQueue() function in the state store, but nothing in the code calls it — and it's all-or-nothing anyway, so it'd wipe your queued voice/rate/punctuation settings too.)
> 
> 2. In-flight synthesis leak. Even after a stop, a chunk already inside synthesizer.write() keeps emitting audio buffers that get scheduled into the next utterance, so a fragment of the old speech tails into the new one.
> 
> The fix (which I've been running daily for weeks with no more out-of-order speech):
> 
> - On stop, do a selective flush of the pending queue — drop the speech/audio items but keep the queued settings commands (voice, rate, punctuation). A full flush breaks things: you lose the punctuation command and start hearing "dot," "comma," etc.
> - Add a generation counter: every stop bumps it, and buffers from an older generation are dropped in the write callback. That kills the in-flight leak.
> 
> (The same patched build also splits chunks on sentence/clause boundaries instead of a raw ~15-word count, which fixed a separate mid-sentence-prosody problem — but the two fixes above are the ones that address your out-of-order issue specifically.)
> 
> My friendly AI assistant has suggested that I get these upstream to robertmeta, but I've never opened a pull request before, so I'm not sure of the right etiquette here, or how I would even do it, though it looks easy enough to figure out. So I'll put it to you: would a PR be welcome, or is it better to just email the patch/diff directly? Happy to do either. And Parham, I'm glad to send you the diff off-list in the meantime if you want to try it or look at the approach. 
> 
> Best,
> Andrew