Emacspeak discussion list

[Parham Doustdar <parham90 AT gmail.com>]

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 AT fastmail.com> 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