[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Regression: Pipewire 0.63 breaks emacspeak-espeak-server



[I'm copying Simon because I've been amazed at how good his advice is
for debugging complicated problems.  I totally understand if you don't
have time to even suggest where I should look].

TL;DR: pipewire 0.63 breaks my accessibility environment.  I'm hoping
for debugging suggestions that will allow me to get to a place where I
can write reasonable bug reports either against libespeak-ng, pcaudiolib or
pipewire-pulse.

I depend on emacspeak for all my interactions with console apps, so
basically all development tools.
I discovered upgrading from pipewire 0.59 to pipewire 0.63 that
Feel free to skip to the line of underscores for some more technical
details about how pipewire is involved in this.

emacspeak's espeak-ng support breaks.
In particular, when emacspeak is started, it speaks  "Espeak 1.50
espeak" but fails to speak any of Emacspeak's startup messages.
Restarting espeak will again speak the espeak version, but nothing else.

I reproduced that emacspeak's espeak support does not work in a clean VM
today, and so I'm starting to trace this down.

To reproduce:

* install pipewire, pipewire-pulse, wireplumber

* install emacspeak-espeak-server and emacspeak

* Select espeak  when debconf asks how you want speech

* Confirm your VM has audio at all

* create a user in the audio group

* su to that user

* run emacspeak

Expected behavior: almost all emacs commands speak

Observed behavior: speech stops after the initialespeak version

________________________________________

Emacspeak directly uses the espeak-ng library in audio playback mode.
In that mode,  espeak-ng uses pcaudiolib for audio output.

If you take a look at create_audio_device_object in pcaudiolib's
src/audio.c, on a linux-like platform it

* First tries to create a pulse audio object

* Then tries to create an alsa audio object

going up one level, libespeak-ng stores the audio object it is using in
the my_audio variable in the library.  I confirmed in the tclsh process
for the emacspeak-espeak server that my_audio pointed to a pulse audio
object (based on the function pointers in the object).
So, it looks like emacspeak's espeak speech server is using the pulse
protocol to communicate ultimately with pipewire.

(I've also confirmed by setting a break point on pulseaudio_is_available
that libespeak-ng is setting up a pulse object when called say by the
espeak-ng command line application).


The espeak-ng command line application does appear to work fine.
However, there's a big difference between how emacspeak uses espeak and
how espeak-ng's command line works.

Emacspeak is going to allow the audio object to become completely empty
(underflow condition) regularly and will then write to the object.
That's because emacspeak will    generate speech in response to ongoing
realtime interactions, where as espeak-ng's CLI will generate all the
speech it's going to generate until it is done and then never generate
audio.


What I could use help with is how to debug what's going on from here.
Why isn't it speaking when it stops speaking.
So, I'm looking for ways to debug the state of the stream within
pipewire or pipewire-pulse, or something like that.
Or alternatively to look at what changed between 0.59 and 0.63 related
to handling pulse streams, particularly pulse streams that might
underflow.

I've generally found pipewire upstream to be helpful, and I'm happy to
engage, but I'd love to have something more well-formed than what I have
to day before doing that.

Any help on where to go next would be appreciated.

--Sam

Attachment: signature.asc
Description: PGP signature


Reply to: