Espeakup frequently goes silent claiming "error: Device or resource busy"

[XLTechie]

I recently tried installing Debian Bookworm with the supposedly talking installer. Unfortunately, I found that the installer stopped talking within the first five minutes of the installation, sometimes within the first minute, no matter how often I retried. Finally finished with sighted assistance over video call, which was a trial for both of us.

On the running system, over the past month, I have continued to have the problem where the system randomly stops speaking after a few seconds or minutes of screen reading.

I have tracked this problem to ESpeakup. Both the version shipped with Bookworm, and the compiled version I made based on git sources from August, 2025.

Espeakup: v0.90-14-gdc1f1b9
System: Linux 6.1.0-38-amd64

When run in the foreground, it gives the following as the only (rather unhelpful) error, when it stops speaking:

error: Device or resource busy

Which device? Which resource? Not specified. I imagine it is the FIFO being used to communicate with Espeak-NG, but I suppose it could be happening during the read from the softsynth as well.

This error will be emitted several times in a row, and speech doesn't always stop after the first one.
When speech stops, Espeakup hangs, it does not immediately exit. It takes a SIGKILL to kill it, meaning even SystemD hangs when trying to restart it.

As a result, to make sure I always have speech after, at most, a 30 second silence, I have a script that does a killall -9 espeakup every 30 seconds, whereupon SystemD restarts it instantly. But this is very disruptive, and often causes a line of output to be truncated while reading, if Espeakup hasn't yet failed in that cycle. Other times it will stop speaking right after the latest restart, and I will have to wait the 30 seconds for speech to return.

I thought this might be related to #45, but it is only hanging, and there is an error. It is not dying, even if I would prefer it did. If it just self-terminated on this device error, SystemD would respawn it, and this would be less of a headache (though still annoying).

Additionally, when Espeakup restarts, speech fades in. It is fast, but it is as if it has to overcome a noise gate before starting. That only began with the latest compile, not the Bookworm shipped version as far as I can remember.

It's sad to be getting this behavior on a new Intel 64-bit I7 system with 32GB RAM and multiple cores, when Espeakup ran fine for decades on the former system in this environment: a 1.2GHZ 32-bit laptop with 2GB RAM, one core, and very old libraries.

Happy to try to provoke a core dump or do something else that might provide more debugging information. This is getting intolerable.

[sthibaul]

When run in the foreground, it gives the following as the only (rather unhelpful) error, when it stops speaking:

error: Device or resource busy

There isn't any such message within the espeakup binary... There however is in libespeak-ng. Would you be able to recompiled espeak-ng with this patch?

patch.txt

depending whether it's the open/reopen, write, or flush/drain, we'll be able to investigate more.

In case it's the open/reopen that fails, would it be possible that you have some program opening the audio device?

I thought this might be related to #45, but it is only hanging, and there is an error.

They still might be related...

It is not dying, even if I would prefer it did. If it just self-terminated on this device error, SystemD would respawn it, and this would be less of a headache (though still annoying).

In my patch, you could add exit(1) after the fprintf(stderr,"error:...); to force termination, for your conveniency while we are fixing the actual issue.

Additionally, when Espeakup restarts, speech fades in. It is fast, but it is as if it has to overcome a noise gate before starting. That only began with the latest compile, not the Bookworm shipped version as far as I can remember.

That's odd and looks like an issue in the ALSA sound system itself...

It's sad to be getting this behavior on a new Intel 64-bit I7 system with 32GB RAM and multiple cores, when Espeakup ran fine for decades on the former system in this environment: a 1.2GHZ 32-bit laptop with 2GB RAM, one core, and very old libraries.

Most bugs don't care much about the speed of your system...

[XLTechie]

@sthibaul

Would you be able to recompiled espeak-ng with this patch?

Yes. Will do, with and without the exit, and report back.

In case it's the open/reopen that fails, would it be possible that you have some program opening the audio device?

Any advice where to look for that on a very vanilla minimalist Debian Bookworm install? I mean, it even happens on the generic install media. The only thing intentionally using sound is the speech stack, so it would have to be something in the background.
I suppose I could do some lsof diffs, but I don't know of anything obvious, and if all it takes is an espeakup SIGKILL and restart, whatever it is is likely unsuccessful. In other words, catching it in the act would be rather tricky, unless you know of a method.

It's sad to be getting this behavior on a new Intel 64-bit I7 system with 32GB RAM and multiple cores, when Espeakup ran fine for decades on the former system in this environment: a 1.2GHZ 32-bit laptop with 2GB RAM, one core, and very old libraries.

Most bugs don't care much about the speed of your system...

No, but they may about the architecture, and the available resources. Surely this can't be happening to everyone who tries to use the Debian talking install procedure, or systems that result therefrom, or you would have heard about it before now. Even issue #45 is, at most, one or two reporters experiencing it. So there has to be something irregular or unique about my environment.

One thing I did think of, is that before I was using Pulseaudio, but now am using basic ALSA. I hadn't wanted to bother with Pulse on this system, though will if it solves the problem somehow.
Okay, off to try your patch. Thanks for laying the groundwork to debug this.

[sthibaul]

It's sad to be getting this behavior on a new Intel 64-bit I7 system with 32GB RAM and multiple cores, when Espeakup ran fine for decades on the former system in this environment: a 1.2GHZ 32-bit laptop with 2GB RAM, one core, and very old libraries.

Most bugs don't care much about the speed of your system...

No, but they may about the architecture, and the available resources.

Ah, sorry, I didn't realize the misunderstanding: in “Device or resource busy” they don't mean that there is not enough resources (cpu, memory, etc.) but simply that something else is keeping the sound card busy.

So there has to be something irregular or unique about my environment.

Yes. But not the software environment since it also happens within the installer.

One thing I did think of, is that before I was using Pulseaudio, but now am using basic ALSA.

Pulseaudio brings some mixing on top of ALSA, yes. Possibly the ALSA driver have issues with your particular sound card.

[sthibaul]

error: Device or resource busy

Also, which ALSA driver is used here? Possibly we can find in the driver what is returning EBUSY.