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

[Jerry Sievers <gsievers19@xxxxxxxxxxx>]

Andrew, Parham, et al;

Curious if this work has been further vetted and/or the patches were
upstreamed (anywhere.)

The official SwiftMac repo looks silent as for any recent issue filings,
pull requests or updates on any of the branches there.

I'd be interested in having the patches and testing them myself, thus
Andrew, I may email you off list to request them as you mentioned being
willing to share.

I'm in the same boat as for not enough Swift development skill to sink
my teeth in readily  and also curious if anyone else on here has tried
the patches.

The details of how such a program as SwiftMac are IMO devilish in
complexity and I did take a good shot at getting up to speed in Swift
more than a year back but without getting comfortable enough nor
following through at the time :-(

NOr for that matter have I recently checked to see if XCode and
VoiceOVer were useable enough to get through it, which it seemed to me
was essential to master for navigating the whole Swift ecosystem.

I'm aware of some other backends that are being used by others but for
the moment much rather stick with the smallest changeset that gets the
job done.

The SwiftMac server is rediculously performant from my experience but
does get all borked up often enough though to be an issue, as you've
experienced.

Cheers!

Thanks



"aleland.tech.list" (via emacspeak Mailing List)
<emacspeak@xxxxxxxxxxxxx> writes:

> 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
>
> Emacspeak discussion list -- emacspeak@xxxxxxxxxxxxx
> To unsubscribe send email to:
> emacspeak-request@xxxxxxxxxxxxx with a subject of: unsubscribe