Speech-dispatcher lockups

[nolan]

I've been playing with various speech combinations for a while, and have
decided that SD and Pulse is really the best for my needs. SD and ALSA
introduce tiny audio drop-outs every few seconds in speech which at
particularly high rates sound like typos. Combine that with the fact
that audio doesn't restore cleanly on restore from suspend unless I'm
using pulse, and ALSA is an option with its own set of unappealing
drawbacks.

I know that people have experienced these lockups before, as I've seen
them posted to the Orca list. Fairly often, SD locks up and needs to be
restarted. I know it was suggested that these problems could be lessened
by switching back to ALSA, and they did a bit, but they didn't go away
entirely. I've created a hotkey under X that restarts SD, but speech is
a service that really shouldn't crash often as it then leaves users in
an unknown state. Another issue I had until today was that when SD is
gone, I can't navigate my system to obtain logs of the error.. When it's
running again, the old logs are replaced by the new ones. I just
modified my hotkey to take a snapshot of the log directory before
killing and restarting SD, and I think I have some helpful data. There
seem to be two types of crashes. One stops all speech entirely. The
other starts the dummy output driver. I haven't correlated either crash
to a specific error, but here are the two I receive:

E: queue.c: Assertion 'q->front' failed at pulsecore/queue.c:83,
function pa_queue_push(). Aborting.

And the other:

E: mainloop.c: Assertion 'e->mainloop->n_enabled_defer_events > 0'
failed at pulse/mainloop.c:288, function mainloop_defer_enable().
Aborting.

I've gone through 4-5 crashes in the past 20 minutes or so, and those
seem to be the only two errors. They appear in espeak.log.

Not sure if this helps, but here's Ubuntu's crash report:

http://dl.getdropbox.com/u/147071/_usr_lib_speech-dispatcher-modules_sd_espeak.1000.crash

Update: So looking through the list archives reveals this to be a
regular and known issue. Is there no fix? I tried hacking at the code
myself, but to no avail, not surprising since I'm no C coder. It seems
like SD should at least try restarting modules in the case of a broken
pipe, Or maybe it does and I'm just not seeing that in the log? Either
way, it's a frustrating issue, and SD is the only app that fails this
spectacularly under Pulse, and since things seem much snappier under
ALSA 1.0.19, the other major issue of latency is even becoming less so.
I tried adding reload_output_module calls at points in the code where
broken pipes apparently resulted. Even if I lose a character or two of
speech, that's preferable to losing *everything* and having to restart.
Is there any other information I might provide to help bring about a fix
for this? If I had another computer to test with and could afford to
kill accessibility again, I'd see if I could at least hack together
something to restart the module on crash, but for the moment I'm just
using my netbook.

Thanks.