Re: Regression: Pipewire 0.63 breaks emacspeak-espeak-server
> "Jason" == Jason White writes: Jason> Have you considered running Git bisect on Pipewire to Jason> identify the commit responsible? That sounds like a lot of work. I don't know if the Debian packaging includes all upstream commits, and I'm not particularly psyched to run a project as big as pipewire without packaging. Also, it would be a fairly manual bisection. I don't know how to tell if it is talking other than to listen. My next step is actually going to be to try to produce a small repro test case directly against libespeak-ng. Basically test the hypothesis that what breaks is saying something waiting a bit then saying something else. If not, I suspect it'll be fun with the debugger and ltrace time. --Sam
Re: Regression: Pipewire 0.63 breaks emacspeak-espeak-server
On 31/12/22 18:24, Paul Gevers wrote: It may be good to be aware that there are multiple upstream versions of emacspeak available that I haven't packaged for Debian yet. Irrespective of Linux distribution, I typically run Emacspeak directly from its Git repository, with code in my Emacs init file to invoke it. However, I think the packaging efforts are valuable and important, especially for those who only want to run released versions or who aren't yet ready to put the necessary Emacs configuration in place.
Re: Regression: Pipewire 0.63 breaks emacspeak-espeak-server
Hi Sam, On 30-12-2022 22:35, Sam Hartman wrote: TL;DR: pipewire 0.63 breaks my accessibility environment. It may be good to be aware that there are multiple upstream versions of emacspeak available that I haven't packaged for Debian yet. I don't recall what exactly, but there was something (DSFG related I think) in one of the versions that would be quite some work so it prevented me from uploading (ENOENERGY). Hence we're 4 versions behind. Paul OpenPGP_signature Description: OpenPGP digital signature
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 willgenerate 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
Re: Regression: Pipewire 0.63 breaks emacspeak-espeak-server
Have you considered running Git bisect on Pipewire to identify the commit responsible? On 31/12/22 08:35, Sam Hartman wrote: [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 willgenerate 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
