[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