Re: Regression: Pipewire 0.63 breaks emacspeak-espeak-server
On 12/30/22 22:35, Sam Hartman wrote:
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.
I would increase the log verbosity to debugging.
Or alternatively to look at what changed between 0.59 and 0.63 related
Basically you need to 'git diff' with a 'revision' and.
Git 'blame' might also be useful.
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, who is this Simon you are talking about?
It's unclear to me who did what (are you acting as a proxy) with regard
to isolate the issue and try to troubleshoot it.
--
John Doe
Reply to: