Re: Orca/espeakup loud audio on login screen and..
Hi Jason, I must say i did not know the keyboard had media keys, but they only work after i have logged into and am on the desktop.. So i havent been able to adjust sound level on login screen and also tried to enable/disable screen reader on login screen which also did not work. I have change the keys for the enable/disable screen reader to ctrl + alt + s since the super key dosent get registred properly.. Best kind regards Kenneth Den 24.09.2024 kl. 18.48 skrev Jason J.G. White: On 24/9/24 09:18, Kenneth Schack Banner wrote: When starting the computer, it comes to the login window and the audio is extremely loud, untill logged in, then the audio level is okay / low. What could be the reason that the login screen has one level of audio, but when logged in, its another audio level? The most likely reason is that the audio configurations are separate. The login manager obviously doesn't run under the account of any of the users on the machine; it runs under a system account. Have you tried using the media keys, if any, to adjust the volume at the login prompt?
Re: Orca/espeakup loud audio on login screen and..
On 24/9/24 09:18, Kenneth Schack Banner wrote: When starting the computer, it comes to the login window and the audio is extremely loud, untill logged in, then the audio level is okay / low. What could be the reason that the login screen has one level of audio, but when logged in, its another audio level? The most likely reason is that the audio configurations are separate. The login manager obviously doesn't run under the account of any of the users on the machine; it runs under a system account. Have you tried using the media keys, if any, to adjust the volume at the login prompt?
Orca/espeakup loud audio on login screen and..
Hi, Im trying to make my sons computer run Linux Debian, but feel like im hitting an issue with Orca/espeakup. I have installed Debian 12.7 with Cinnamon as desktop, why lightdm is the window manager. When starting the computer, it comes to the login window and the audio is extremely loud, untill logged in, then the audio level is okay / low. What could be the reason that the login screen has one level of audio, but when logged in, its another audio level? I have also now, tried to disable the screen reader service, but it still auto starts, i ran this command: sudo systemtl disable espeakup.service (Im using espeakup in Orca) After the login, the screen reader is also speaking, but there is no service on it? Best kind regards Kenneth
Re: espeakup stops speaking D-i bookworm amd64 on 11gen Lenovo Carbon X1
Hi Tom, On May 28, 2024, at 08:40, Tom Moore wrote: > > Hi, > I have noticed Speakup being unstable on Arm64 as well. > This seems to be limited to this arch from what I can tell. > Amd64 works fine. > One thing I notice is that the first 10th of a second or so the speech > cuts off. > For example when reading by character half of the character is not > spoken by speakup. > > My exact setup is a Vmware fusion guest on an m2 pro based mac. I noticed this behavior also, specifically with VMware. I do not believe this is a bug with espeakup, as the performance with qemu arm64 is fantastic, a part from this long standing issue of speech stopping. --FC > > Tom > > On 2024-05-26, Sam Hartman wrote: >> >> >> Hi. >> I was installing on a 11th gen Lenovo Carbon X1 last night, and against >> my typical practice I decided to try D-I. >> I ran into something that looks a lot like the espeakup hangs that >> people have been struggling with on arm64. >> >> I was using the 12.5 netinst iso for amd64. >> The installer would speak for a while and then suddenly stop. >> >> If I dropped to a shell on ctrl-alt-f2 and then killed `pidof espeakup` >> and restarted espeakup, things would continue. >> Interestingly after I restarted espeakup it tended to get more stable. >> >> I was more interested in installing my system (after which I do not >> typically use espeakup much) than in debugging. >> However it is easy enough for me to reproduce. >> Unfortunately, d-i isn't the greatest environment for debugging >> something like this. >> >> I thought it was interesting because if the problem is broader than >> arm64, it might be easier to approach. >> >> --Sam >> >> >
Re: espeakup stops speaking D-i bookworm amd64 on 11gen Lenovo Carbon X1
Hi, I have noticed Speakup being unstable on Arm64 as well. This seems to be limited to this arch from what I can tell. Amd64 works fine. One thing I notice is that the first 10th of a second or so the speech cuts off. For example when reading by character half of the character is not spoken by speakup. My exact setup is a Vmware fusion guest on an m2 pro based mac. Tom On 2024-05-26, Sam Hartman wrote: > > > Hi. > I was installing on a 11th gen Lenovo Carbon X1 last night, and against > my typical practice I decided to try D-I. > I ran into something that looks a lot like the espeakup hangs that > people have been struggling with on arm64. > > I was using the 12.5 netinst iso for amd64. > The installer would speak for a while and then suddenly stop. > > If I dropped to a shell on ctrl-alt-f2 and then killed `pidof espeakup` > and restarted espeakup, things would continue. > Interestingly after I restarted espeakup it tended to get more stable. > > I was more interested in installing my system (after which I do not > typically use espeakup much) than in debugging. > However it is easy enough for me to reproduce. > Unfortunately, d-i isn't the greatest environment for debugging > something like this. > > I thought it was interesting because if the problem is broader than > arm64, it might be easier to approach. > > --Sam > >
Re: espeakup stops speaking D-i bookworm amd64 on 11gen Lenovo Carbon X1
Hi. I was installing on a 11th gen Lenovo Carbon X1 last night, and against my typical practice I decided to try D-I. I ran into something that looks a lot like the espeakup hangs that people have been struggling with on arm64. I was using the 12.5 netinst iso for amd64. The installer would speak for a while and then suddenly stop. If I dropped to a shell on ctrl-alt-f2 and then killed `pidof espeakup` and restarted espeakup, things would continue. Interestingly after I restarted espeakup it tended to get more stable. I was more interested in installing my system (after which I do not typically use espeakup much) than in debugging. However it is easy enough for me to reproduce. Unfortunately, d-i isn't the greatest environment for debugging something like this. I thought it was interesting because if the problem is broader than arm64, it might be easier to approach. --Sam
Re: espeakup stops speaking bookworm arm64
Waking up this thread. Samuel and others. Please let us know what we can do to help get this one sorted. Thanks so much. --FC > On Jan 23, 2024, at 08:20, Geoff Shang wrote: > > On Sat, 6 Jan 2024, Samuel Thibault wrote: > >> Geoff Shang, le jeu. 04 janv. 2024 15:04:22 +0200, a ecrit: >>> I updated the core file at http://quitelikely.com/gcore >> >> Thanks, that's indeed still the same situation: an alsa-lib mutex is >> said to be held by a thread which is not executing alsa-lib code. > > What's the next step then? > > Cheers, > Geoff. >
Re: espeakup stops speaking bookworm arm64
On Sat, 6 Jan 2024, Samuel Thibault wrote: Geoff Shang, le jeu. 04 janv. 2024 15:04:22 +0200, a ecrit: I updated the core file at http://quitelikely.com/gcore Thanks, that's indeed still the same situation: an alsa-lib mutex is said to be held by a thread which is not executing alsa-lib code. What's the next step then? Cheers, Geoff.
Re: espeakup stops speaking bookworm arm64
Samuel, I know that I don't have anything interesting about my alsa config. I'd try your new espeak packages but I'm on arm64. My bookworm system was built from your modified debian installer. I have just built a trixie arm64 machine today, if that would be more helpful. Best, --FC
Re: espeakup stops speaking bookworm arm64
On Sat, 6 Jan 2024, Samuel Thibault wrote: Geoff Shang, le jeu. 04 janv. 2024 15:04:22 +0200, a ecrit: I updated the core file at http://quitelikely.com/gcore Thanks, that's indeed still the same situation: an alsa-lib mutex is said to be held by a thread which is not executing alsa-lib code. Are you perhaps running some particular alsa configuration? No. I just updated my Bullseye VM to Bookworm as documented in the release notes. I've not touched the ALSA configuration. HTH, Geoff.
Re: espeakup stops speaking bookworm arm64
Geoff Shang, le jeu. 04 janv. 2024 15:04:22 +0200, a ecrit:
> On Thu, 4 Jan 2024, Samuel Thibault wrote:
>
> > Geoff Shang, le jeu. 04 janv. 2024 14:42:29 +0200, a ecrit:
> > > On Thu, 4 Jan 2024, Samuel Thibault wrote:
> > >
> > > > Geoff Shang, le jeu. 04 janv. 2024 14:26:49 +0200, a ecrit:
> > > > > On Wed, 3 Jan 2024, Samuel Thibault wrote:
> > > > >
> > > > > > This confirms that "the impossible" has happened :)
> > > > > >
> > > > > > The alsa-lib lock reports a mutex being held by a thread that is not
> > > > > > actually running alsa-lib functions.
> > > > > > {snip}
> > > > You can also as well just download the .deb file :)
> > > >
> > > I see that you also have libespeak-ng1-dbgsym
> > >
> > > Would you like me to install that too?
> >
> > That'll be useful for gdb debugging, but not to check whether it works
>
> It didn't.
Ok :/
> I updated the core file at http://quitelikely.com/gcore
Thanks, that's indeed still the same situation: an alsa-lib mutex is
said to be held by a thread which is not executing alsa-lib code.
Are you perhaps running some particular alsa configuration?
Samuel
Re: espeakup stops speaking bookworm arm64
On Thu, 4 Jan 2024, Samuel Thibault wrote:
Geoff Shang, le jeu. 04 janv. 2024 14:42:29 +0200, a ecrit:
On Thu, 4 Jan 2024, Samuel Thibault wrote:
Geoff Shang, le jeu. 04 janv. 2024 14:26:49 +0200, a ecrit:
On Wed, 3 Jan 2024, Samuel Thibault wrote:
This confirms that "the impossible" has happened :)
The alsa-lib lock reports a mutex being held by a thread that is not
actually running alsa-lib functions.
{snip}
You can also as well just download the .deb file :)
I see that you also have libespeak-ng1-dbgsym
Would you like me to install that too?
That'll be useful for gdb debugging, but not to check whether it works
It didn't.
I updated the core file at http://quitelikely.com/gcore
HTH,
Geoff.
Re: espeakup stops speaking bookworm arm64
Geoff Shang, le jeu. 04 janv. 2024 14:42:29 +0200, a ecrit: > On Thu, 4 Jan 2024, Samuel Thibault wrote: > > > Geoff Shang, le jeu. 04 janv. 2024 14:26:49 +0200, a ecrit: > > > On Wed, 3 Jan 2024, Samuel Thibault wrote: > > > > > > > This confirms that "the impossible" has happened :) > > > > > > > > The alsa-lib lock reports a mutex being held by a thread that is not > > > > actually running alsa-lib functions. > > > > > > > I looked at the ReadMe on your site and it said to run the following to > > > import your apt key: > > > > > > sudo apt-key adv --recv-keys --keyserver keyring.debian.org > > > 900CB024B67931D40F82304BD0178C767D069EE6 > > > > > > But when I try, I get the following error: > > > > > > Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d > > > instead (see apt-key(8)). > > > Executing: /tmp/apt-key-gpghome.N9pKWsZ2Uo/gpg.1.sh --recv-keys > > > --keyserver > > > keyring.debian.org 900CB024B67931D40F82304BD0178C767D069EE6 > > > gpg: keyserver receive failed: Server indicated a failure > > > > Uh? It does work here. > > Interesting... > > > > Is there another way that I can get your key? > > > > Here it is, you can use apt-key add /tmp/sthibault.gpg > > I just copied it into /etc/apt/trusted.gpg.d as instructed by apt-key(8). > > > You can also as well just download the .deb file :) > > > I see that you also have libespeak-ng1-dbgsym > > Would you like me to install that too? That'll be useful for gdb debugging, but not to check whether it works :) Samuel
Re: espeakup stops speaking bookworm arm64
On Thu, 4 Jan 2024, Geoff Shang wrote: On Thu, 4 Jan 2024, Samuel Thibault wrote: Geoff Shang, le jeu. 04 janv. 2024 14:26:49 +0200, a ecrit: On Wed, 3 Jan 2024, Samuel Thibault wrote: This confirms that "the impossible" has happened :) The alsa-lib lock reports a mutex being held by a thread that is not actually running alsa-lib functions. [snip] I see that you also have libespeak-ng1-dbgsym Would you like me to install that too? Never mind. I saw that not installing it would remove my existing version, which is not surprising, so I went ahead and installed it. Cheers, Geoff. \
Re: espeakup stops speaking bookworm arm64
On Thu, 4 Jan 2024, Samuel Thibault wrote: Geoff Shang, le jeu. 04 janv. 2024 14:26:49 +0200, a ecrit: On Wed, 3 Jan 2024, Samuel Thibault wrote: This confirms that "the impossible" has happened :) The alsa-lib lock reports a mutex being held by a thread that is not actually running alsa-lib functions. I looked at the ReadMe on your site and it said to run the following to import your apt key: sudo apt-key adv --recv-keys --keyserver keyring.debian.org 900CB024B67931D40F82304BD0178C767D069EE6 But when I try, I get the following error: Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)). Executing: /tmp/apt-key-gpghome.N9pKWsZ2Uo/gpg.1.sh --recv-keys --keyserver keyring.debian.org 900CB024B67931D40F82304BD0178C767D069EE6 gpg: keyserver receive failed: Server indicated a failure Uh? It does work here. Interesting... Is there another way that I can get your key? Here it is, you can use apt-key add /tmp/sthibault.gpg I just copied it into /etc/apt/trusted.gpg.d as instructed by apt-key(8). You can also as well just download the .deb file :) I see that you also have libespeak-ng1-dbgsym Would you like me to install that too? Cheers, Geoff.
Re: espeakup stops speaking bookworm arm64
On Wed, 3 Jan 2024, Samuel Thibault wrote: This confirms that "the impossible" has happened :) The alsa-lib lock reports a mutex being held by a thread that is not actually running alsa-lib functions. I however noticed that espeak-ng uses pcaudiolib without any locking, and pcaudiolib is definitely not threadsafe. On https://people.debian.org/~sthibault/tmp/bookworm-tmp I have put some libespeak updates (version 1.51+dfsg-10+pcaudioliblock) that add locking, could try to install libespeak-ng1 from there, and see if you can still reproduce the issue? I looked at the ReadMe on your site and it said to run the following to import your apt key: sudo apt-key adv --recv-keys --keyserver keyring.debian.org 900CB024B67931D40F82304BD0178C767D069EE6 But when I try, I get the following error: Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)). Executing: /tmp/apt-key-gpghome.N9pKWsZ2Uo/gpg.1.sh --recv-keys --keyserver keyring.debian.org 900CB024B67931D40F82304BD0178C767D069EE6 gpg: keyserver receive failed: Server indicated a failure Is there another way that I can get your key? Cheers, Geoff.
Re: espeakup stops speaking bookworm arm64
Hello, Geoff Shang, le mar. 02 janv. 2024 15:33:20 +0200, a ecrit: > On Mon, 1 Jan 2024, Samuel Thibault wrote: > > > Hello, > > > > Geoff Shang, le lun. 01 janv. 2024 18:39:33 +0200, a ecrit: > > > On Sun, 31 Dec 2023, Samuel Thibault wrote: > > > > Frank Carmickle, le ven. 29 déc. 2023 20:46:21 -0500, a ecrit: > > > > > On Dec 29, 2023, at 15:54, Samuel Thibault > > > > > wrote: > > > > > > > #4 0x7fbedbb1a006 in snd_pcm_state () from > > > > > > > /lib/x86_64-linux-gnu/libasound.so.2 > > > > > > > No symbol table info available. > > > > > > > #9 0x7fbedb7fd872 in alsa_object_close () from > > > > > > > /lib/x86_64-linux-gnu/libpcaudio.so.0 > > > > > > > No symbol table info available. > > > > > > > > > > > > Would you be able to reproduce with these packages installed? > > > > > > > > > > > > libpcaudio0-dbgsym > > > > > > libasound2-dbgsym > > > > > > > > > > I have done, as Geoff has done, with these additional symbols. > > > > > > > > Was that really in the stuck case? Your traces don't show anything that > > > > seems to be stuck. > > > > > > Try this. > > > > Thanks! This is indeed the stuck condition I was looking for. > > > > I'm still baffled how we can end up in such a condition, I'd need to be > > able to perform more investigation. Perhaps you can trigger a core file > > generation by telling to gdb: > > > > generate-core-file /tmp/gcore > > > > and put it somewhere on the Internet for me to fetch it? > > http://quitelikely.com/gcore > > It's 300 mb. Thanks! This confirms that "the impossible" has happened :) The alsa-lib lock reports a mutex being held by a thread that is not actually running alsa-lib functions. I however noticed that espeak-ng uses pcaudiolib without any locking, and pcaudiolib is definitely not threadsafe. On https://people.debian.org/~sthibault/tmp/bookworm-tmp I have put some libespeak updates (version 1.51+dfsg-10+pcaudioliblock) that add locking, could try to install libespeak-ng1 from there, and see if you can still reproduce the issue? Samuel
Re: espeakup stops speaking bookworm arm64
On Mon, 1 Jan 2024, Samuel Thibault wrote: Hello, Geoff Shang, le lun. 01 janv. 2024 18:39:33 +0200, a ecrit: On Sun, 31 Dec 2023, Samuel Thibault wrote: Frank Carmickle, le ven. 29 déc. 2023 20:46:21 -0500, a ecrit: On Dec 29, 2023, at 15:54, Samuel Thibault wrote: #4 0x7fbedbb1a006 in snd_pcm_state () from /lib/x86_64-linux-gnu/libasound.so.2 No symbol table info available. #9 0x7fbedb7fd872 in alsa_object_close () from /lib/x86_64-linux-gnu/libpcaudio.so.0 No symbol table info available. Would you be able to reproduce with these packages installed? libpcaudio0-dbgsym libasound2-dbgsym I have done, as Geoff has done, with these additional symbols. Was that really in the stuck case? Your traces don't show anything that seems to be stuck. Try this. Thanks! This is indeed the stuck condition I was looking for. I'm still baffled how we can end up in such a condition, I'd need to be able to perform more investigation. Perhaps you can trigger a core file generation by telling to gdb: generate-core-file /tmp/gcore and put it somewhere on the Internet for me to fetch it? http://quitelikely.com/gcore It's 300 mb. HTH, Geoff.
Re: espeakup stops speaking bookworm arm64
Hello, Geoff Shang, le lun. 01 janv. 2024 18:39:33 +0200, a ecrit: > On Sun, 31 Dec 2023, Samuel Thibault wrote: > > Frank Carmickle, le ven. 29 déc. 2023 20:46:21 -0500, a ecrit: > > > On Dec 29, 2023, at 15:54, Samuel Thibault wrote: > > > > > #4 0x7fbedbb1a006 in snd_pcm_state () from > > > > > /lib/x86_64-linux-gnu/libasound.so.2 > > > > > No symbol table info available. > > > > > #9 0x7fbedb7fd872 in alsa_object_close () from > > > > > /lib/x86_64-linux-gnu/libpcaudio.so.0 > > > > > No symbol table info available. > > > > > > > > Would you be able to reproduce with these packages installed? > > > > > > > > libpcaudio0-dbgsym > > > > libasound2-dbgsym > > > > > > I have done, as Geoff has done, with these additional symbols. > > > > Was that really in the stuck case? Your traces don't show anything that > > seems to be stuck. > > Try this. Thanks! This is indeed the stuck condition I was looking for. I'm still baffled how we can end up in such a condition, I'd need to be able to perform more investigation. Perhaps you can trigger a core file generation by telling to gdb: generate-core-file /tmp/gcore and put it somewhere on the Internet for me to fetch it? Thanks, Samuel
Re: espeakup stops speaking bookworm arm64
On Sun, 31 Dec 2023, Samuel Thibault wrote:
Hello,
Frank Carmickle, le ven. 29 déc. 2023 20:46:21 -0500, a ecrit:
On Dec 29, 2023, at 15:54, Samuel Thibault wrote:
#4 0x7fbedbb1a006 in snd_pcm_state () from
/lib/x86_64-linux-gnu/libasound.so.2
No symbol table info available.
#9 0x7fbedb7fd872 in alsa_object_close () from
/lib/x86_64-linux-gnu/libpcaudio.so.0
No symbol table info available.
Would you be able to reproduce with these packages installed?
libpcaudio0-dbgsym
libasound2-dbgsym
I have done, as Geoff has done, with these additional symbols.
Was that really in the stuck case? Your traces don't show anything that
seems to be stuck.
Try this.
Cheers,
Geoff.
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/espeakup...
Reading symbols from
/usr/lib/debug/.build-id/76/62ad26e5f970e59309a544f3864db114aa389e.debug...
Attaching to program: /usr/bin/espeakup, process 4406
[New LWP 4407]
[New LWP 4408]
[New LWP 4409]
[New LWP 4410]
[New LWP 4411]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__futex_abstimed_wait_common64 (private=128, cancel=true, abstime=0x0, op=265,
expected=4407,
futex_word=0x7fdcb29fc990) at ./nptl/futex-internal.c:57
Thread 6 (Thread 0x7fdca3fff6c0 (LWP 4411) "espeakup"):
#0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0,
op=393, expected=0, futex_word=0x7fdcb3a0b1cc )
at ./nptl/futex-internal.c:57
sc_cancel_oldtype = 0
__arg6 =
__arg3 =
_a5 =
_a2 =
sc_ret =
__arg4 =
__arg1 =
_a6 =
_a3 =
resultvar =
__arg5 =
__arg2 =
_a4 =
_a1 =
#1 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x7fdcb3a0b1cc
, expected=expected@entry=0,
clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0,
cancel=cancel@entry=true) at ./nptl/futex-internal.c:87
err =
clockbit = 256
op = 393
#2 0x7fdcb3619e0b in __GI___futex_abstimed_wait_cancelable64
(futex_word=futex_word@entry=0x7fdcb3a0b1cc ,
expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0,
private=private@entry=0) at ./nptl/futex-internal.c:139
No locals.
#3 0x7fdcb361c468 in __pthread_cond_wait_common (abstime=0x0, clockid=0,
mutex=0x7fdcb3a0b1e0 , cond=0x7fdcb3a0b1a0
) at ./nptl/pthread_cond_wait.c:503
spin = 0
buffer = {__routine = 0x7fdcb361c1f0 <__condvar_cleanup_waiting>, __arg
= 0x7fdca3ffedc0, __canceltype = 0, __prev = 0x0}
cbuffer = {wseq = 3103, cond = 0x7fdcb3a0b1a0
, mutex = 0x7fdcb3a0b1e0 , private = 0}
err =
g = 1
flags =
g1_start =
maxspin = 0
signals =
result = 0
wseq = 3103
seq = 1551
private = 0
maxspin =
err =
result =
wseq =
g =
seq =
flags =
private =
signals =
done =
g1_start =
spin =
buffer =
cbuffer =
s =
#4 ___pthread_cond_wait (cond=cond@entry=0x7fdcb3a0b1a0
, mutex=mutex@entry=0x7fdcb3a0b1e0 ) at
./nptl/pthread_cond_wait.c:618
No locals.
#5 0x7fdcb39b04cc in polling_thread (p=) at
src/libespeak-ng/event.c:263
a_stop_is_required = false
__PRETTY_FUNCTION__ = "polling_thread"
#6 0x7fdcb361d044 in start_thread (arg=) at
./nptl/pthread_create.c:442
ret =
pd =
out =
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140585620993728,
-928778118510472200, -136, 2, 140585853774560, 140585612603392,
911159543697183736, 911196051988616184}, mask_was_saved = 0}}, priv = {pad =
{0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call =
#7 0x7fdcb369d61c in clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
No locals.
Thread 5 (Thread 0x7fdcb0dfd6c0 (LWP 4410) "espeakup"):
#0 futex_wait (private=0, expected=2, futex_word=0x7fdca80568d0) at
../sysdeps/nptl/futex-internal.h:146
Re: espeakup stops speaking bookworm arm64
Hello, Frank Carmickle, le ven. 29 déc. 2023 20:46:21 -0500, a ecrit: > On Dec 29, 2023, at 15:54, Samuel Thibault wrote: > > Geoff Shang, le jeu. 21 déc. 2023 19:39:42 +0200, a ecrit: > >> On Thu, 21 Dec 2023, Samuel Thibault wrote: > > This is showing that it's alsa-lib which gets stuck. I tried to dive > > into the source code, but I don't see yet how that can happen, a quick > > review showed me that locking seems to be done properly. I'd probably > > need a closer look since the hang *does* happen. > > > >> #4 0x7fbedbb1a006 in snd_pcm_state () from > >> /lib/x86_64-linux-gnu/libasound.so.2 > >> No symbol table info available. > >> #9 0x7fbedb7fd872 in alsa_object_close () from > >> /lib/x86_64-linux-gnu/libpcaudio.so.0 > >> No symbol table info available. > > > > Would you be able to reproduce with these packages installed? > > > > libpcaudio0-dbgsym > > libasound2-dbgsym > > I have done, as Geoff has done, with these additional symbols. Was that really in the stuck case? Your traces don't show anything that seems to be stuck. Samuel
Re: espeakup stops speaking bookworm arm64
On Dec 29, 2023, at 15:54, Samuel Thibault wrote:
>
> Hello,
>
> Geoff Shang, le jeu. 21 déc. 2023 19:39:42 +0200, a ecrit:
>> On Thu, 21 Dec 2023, Samuel Thibault wrote:
>>
>>> thread apply all bt full
>>>
>>> :)
>>
>> OK, you got it.
>>
>> This produced 20 kb of output, so I've attached it. Let me know if anyone
>> wants it included in the message instead.
>
> Attached is completely fine, thanks a lot!
>
> This is showing that it's alsa-lib which gets stuck. I tried to dive
> into the source code, but I don't see yet how that can happen, a quick
> review showed me that locking seems to be done properly. I'd probably
> need a closer look since the hang *does* happen.
>
>> #4 0x7fbedbb1a006 in snd_pcm_state () from
>> /lib/x86_64-linux-gnu/libasound.so.2
>> No symbol table info available.
>> #9 0x7fbedb7fd872 in alsa_object_close () from
>> /lib/x86_64-linux-gnu/libpcaudio.so.0
>> No symbol table info available.
>
> Would you be able to reproduce with these packages installed?
>
> libpcaudio0-dbgsym
> libasound2-dbgsym
I have done, as Geoff has done, with these additional symbols. Please let us
know if you need anything else. File attached.
Thanks so much, Samuel.
Happy New Year,
--FC
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/espeakup...
Reading symbols from
/usr/lib/debug/.build-id/7c/ee622ad29eb52a84ecd41e5e9cb868d8d27eef.debug...
Attaching to program: /usr/bin/espeakup, process 92856
[New LWP 92857]
[New LWP 92858]
[New LWP 92859]
[New LWP 92860]
[New LWP 92861]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
0x99c4b694 in __futex_abstimed_wait_common64 (private=128,
cancel=true, abstime=0x0, op=265, expected=92857,
futex_word=0x98f5f1b0) at ./nptl/futex-internal.c:57
Thread 6 (Thread 0x96aff0e0 (LWP 92861) "espeakup"):
#0 0x99c4b694 in __futex_abstimed_wait_common64 (private=0,
cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x99ff8c88
) at ./nptl/futex-internal.c:57
_x3tmp = 0
_x0tmp = 281473265405064
_x0 = 281473265405064
_x3 = 0
_x4tmp = 0
_x1tmp = 393
_x1 = 393
_x4 = 0
_x5tmp = 4294967295
_x2tmp = 0
_x2 = 0
_x5 = 4294967295
_x8 = 98
_sys_result =
sc_cancel_oldtype = 0
sc_ret =
_sys_result =
_x5tmp =
_x4tmp =
_x3tmp =
_x2tmp =
_x1tmp =
_x0tmp =
_x0 =
_x1 =
_x2 =
_x3 =
_x4 =
_x5 =
_x8 =
#1 __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0,
clockid=0, expected=0, futex_word=0x99ff8c88
) at ./nptl/futex-internal.c:87
err =
clockbit = 256
op = 393
err =
clockbit =
op =
#2 __GI___futex_abstimed_wait_cancelable64
(futex_word=futex_word@entry=0x99ff8c88 ,
expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0,
private=private@entry=0) at ./nptl/futex-internal.c:139
No locals.
#3 0x99c4e1d0 in __pthread_cond_wait_common (abstime=0x0, clockid=0,
mutex=0x99ff8c28 , cond=0x99ff8c60
) at ./nptl/pthread_cond_wait.c:503
spin = 0
buffer = {__routine = 0x99c4df14 <__condvar_cleanup_waiting>, __arg
= 0x96afe828, __canceltype = -1711305632, __prev = 0x0}
cbuffer = {wseq = 5364, cond = 0x99ff8c60
, mutex = 0x99ff8c28 , private = 0}
err =
g = 0
flags =
g1_start =
maxspin = 0
signals =
result = 0
wseq = 5364
seq = 2682
private = 0
maxspin =
err =
result =
wseq =
g =
seq =
flags =
private =
signals =
done =
g1_start =
spin =
buffer =
cbuffer =
Re: espeakup stops speaking bookworm arm64
Hello, Geoff Shang, le jeu. 21 déc. 2023 19:39:42 +0200, a ecrit: > On Thu, 21 Dec 2023, Samuel Thibault wrote: > > > thread apply all bt full > > > > :) > > OK, you got it. > > This produced 20 kb of output, so I've attached it. Let me know if anyone > wants it included in the message instead. Attached is completely fine, thanks a lot! This is showing that it's alsa-lib which gets stuck. I tried to dive into the source code, but I don't see yet how that can happen, a quick review showed me that locking seems to be done properly. I'd probably need a closer look since the hang *does* happen. > #4 0x7fbedbb1a006 in snd_pcm_state () from > /lib/x86_64-linux-gnu/libasound.so.2 > No symbol table info available. > #9 0x7fbedb7fd872 in alsa_object_close () from > /lib/x86_64-linux-gnu/libpcaudio.so.0 > No symbol table info available. Would you be able to reproduce with these packages installed? libpcaudio0-dbgsym libasound2-dbgsym Thanks, Samuel
Re: espeakup stops speaking bookworm arm64
On Thu, 21 Dec 2023, Samuel Thibault wrote:
thread apply all bt full
:)
OK, you got it.
This produced 20 kb of output, so I've attached it. Let me know if anyone
wants it included in the message instead.
Because of the amount of output and the fact that I had to do it without
speech, I set it up to run the command from the command line and to
redirect the output. The command was:
$ gdb -ex 'thread apply all bt full' /usr/bin/espeakup >
BTW: I just noticed the subject line. This is on amd64 (Debian running
under VMWare Workstation Player on Windows 11 - yes I know...)
Cheers,
Geoff.
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/espeakup...
Reading symbols from
/usr/lib/debug/.build-id/76/62ad26e5f970e59309a544f3864db114aa389e.debug...
Attaching to program: /usr/bin/espeakup, process 1474
[New LWP 1475]
[New LWP 1476]
[New LWP 1477]
[New LWP 1478]
[New LWP 1479]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__futex_abstimed_wait_common64 (private=128, cancel=true, abstime=0x0, op=265,
expected=1475,
futex_word=0x7fbedaca3990) at ./nptl/futex-internal.c:57
Thread 6 (Thread 0x7fbecbfff6c0 (LWP 1479) "espeakup"):
#0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0,
op=393, expected=0, futex_word=0x7fbedbc791cc )
at ./nptl/futex-internal.c:57
sc_cancel_oldtype = 0
__arg6 =
__arg3 =
_a5 =
_a2 =
sc_ret =
__arg4 =
__arg1 =
_a6 =
_a3 =
resultvar =
__arg5 =
__arg2 =
_a4 =
_a1 =
#1 __futex_abstimed_wait_common (futex_word=futex_word@entry=0x7fbedbc791cc
, expected=expected@entry=0,
clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0,
cancel=cancel@entry=true) at ./nptl/futex-internal.c:87
err =
clockbit = 256
op = 393
#2 0x7fbedb887e0b in __GI___futex_abstimed_wait_cancelable64
(futex_word=futex_word@entry=0x7fbedbc791cc ,
expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0,
private=private@entry=0) at ./nptl/futex-internal.c:139
No locals.
#3 0x7fbedb88a468 in __pthread_cond_wait_common (abstime=0x0, clockid=0,
mutex=0x7fbedbc791e0 , cond=0x7fbedbc791a0
) at ./nptl/pthread_cond_wait.c:503
spin = 0
buffer = {__routine = 0x7fbedb88a1f0 <__condvar_cleanup_waiting>, __arg
= 0x7fbecbffedc0, __canceltype = 0, __prev = 0x0}
cbuffer = {wseq = 599, cond = 0x7fbedbc791a0
, mutex = 0x7fbedbc791e0 , private = 0}
err =
g = 1
flags =
g1_start =
maxspin = 0
signals =
result = 0
wseq = 599
seq = 299
private = 0
maxspin =
err =
result =
wseq =
g =
seq =
flags =
private =
signals =
done =
g1_start =
spin =
buffer =
cbuffer =
s =
#4 ___pthread_cond_wait (cond=cond@entry=0x7fbedbc791a0
, mutex=mutex@entry=0x7fbedbc791e0 ) at
./nptl/pthread_cond_wait.c:618
No locals.
#5 0x7fbedbc1e4cc in polling_thread (p=) at
src/libespeak-ng/event.c:263
a_stop_is_required = false
__PRETTY_FUNCTION__ = "polling_thread"
#6 0x7fbedb88b044 in start_thread (arg=) at
./nptl/pthread_create.c:442
ret =
pd =
out =
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140457443063488,
-3844386314597928019, -136, 2, 140457677941472, 140457434673152,
3879966511456351149, 3879930324205335469}, mask_was_saved = 0}}, priv = {pad =
{0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call =
#7 0x00007fbedb90b61c in clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
No locals.
Thread 5 (Thread 0x7fbed8ffd6c0 (LWP 1478) "espeakup"):
#0 futex_wait (private=0, expected=2, futex_word=0x7fbed001ca00) at
../sysdeps/nptl/futex-internal.h:146
__ret = -512
err =
err =
__ret =
Re: espeakup stops speaking bookworm arm64
Geoff Shang, le jeu. 21 déc. 2023 18:50:52 +0200, a ecrit: > On Thu, 21 Dec 2023, Samuel Thibault wrote: > > > All we need now is the full > > > > thread apply bt full > > > > to get the most available information. > > Earlier you said to use > > thread apply all bt > > Which do you want? thread apply all bt full :) Samuel
Re: espeakup stops speaking bookworm arm64
On Thu, 21 Dec 2023, Samuel Thibault wrote: All we need now is the full thread apply bt full to get the most available information. Earlier you said to use thread apply all bt Which do you want? Cheers, Geoff.
Re: espeakup stops speaking bookworm arm64
Frank Carmickle, le jeu. 21 déc. 2023 08:39:31 -0500, a ecrit: > On Dec 20, 2023, at 18:34, Samuel Thibault wrote: > > > > James Addison, le mer. 20 déc. 2023 23:03:33 +, a ecrit: > >> sthibault: do you think this could be related to > >> https://github.com/linux-speakup/espeakup/pull/48 ? > > > > Possibly. Testing would give a definite answer. > > > >>>> It took me a couple of goes, and I lost speech entirely both times (not > >>>> sure why), but I got a trace. > >>>> > >>>> I'm not sure how helpful it is though. > >>>> > >>>> 0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > >>>> (gdb) bt > >>>> #0 0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > >>>> #1 0x7f9de46c4b33 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > >>>> #2 0x5605c505e734 in main (argc=, argv= >>>> out>) > >>>> at ../src/espeakup.c:229 > > > > To get useful information, the libc6-dbg package should be installed, > > and this should be used: > > > > thread apply all bt > > I have installed > > > > Reading symbols from /usr/bin/espeakup... > Reading symbols from > /usr/lib/debug/.build-id/7c/ee622ad29eb52a84ecd41e5e9cb868d8d27eef.debug... > Attaching to program: /usr/bin/espeakup, process 63456 > [New LWP 63457] > [New LWP 63458] > [New LWP 63459] > [New LWP 63460] > --Type for more, q to quit, c to continue without paging--c > [New LWP 63461] > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1". > 0xb81bb694 in __futex_abstimed_wait_common64 (private=128, > cancel=true, abstime=0x0, op=265, expected=63457, > futex_word=0xb74cf1b0) at ./nptl/futex-internal.c:57 > 57 ./nptl/futex-internal.c: No such file or directory. > (gdb) > > What am I missing? It's completely fine that it doesn't have the .c files: I do have them :) "__futex_abstimed_wait_common64" and "./nptl/futex-internal.c:57" are the pieces of information that we do need, the details of the .c files we can work by ourself, provided that we know the versions of the libc6, libespeak-ng1, and espeakup packages. All we need now is the full thread apply bt full to get the most available information. Samuel
Re: espeakup stops speaking bookworm arm64
On Dec 20, 2023, at 18:34, Samuel Thibault wrote: > > James Addison, le mer. 20 déc. 2023 23:03:33 +, a ecrit: >> sthibault: do you think this could be related to >> https://github.com/linux-speakup/espeakup/pull/48 ? > > Possibly. Testing would give a definite answer. > >>>> It took me a couple of goes, and I lost speech entirely both times (not >>>> sure why), but I got a trace. >>>> >>>> I'm not sure how helpful it is though. >>>> >>>> 0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 >>>> (gdb) bt >>>> #0 0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 >>>> #1 0x7f9de46c4b33 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 >>>> #2 0x5605c505e734 in main (argc=, argv=) >>>> at ../src/espeakup.c:229 > > To get useful information, the libc6-dbg package should be installed, > and this should be used: > > thread apply all bt I have installed Reading symbols from /usr/bin/espeakup... Reading symbols from /usr/lib/debug/.build-id/7c/ee622ad29eb52a84ecd41e5e9cb868d8d27eef.debug... Attaching to program: /usr/bin/espeakup, process 63456 [New LWP 63457] [New LWP 63458] [New LWP 63459] [New LWP 63460] --Type for more, q to quit, c to continue without paging--c [New LWP 63461] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1". 0xb81bb694 in __futex_abstimed_wait_common64 (private=128, cancel=true, abstime=0x0, op=265, expected=63457, futex_word=0xb74cf1b0) at ./nptl/futex-internal.c:57 57 ./nptl/futex-internal.c: No such file or directory. (gdb) What am I missing? Thank you, --FC
Re: espeakup stops speaking bookworm arm64
James Addison, le mer. 20 déc. 2023 23:03:33 +, a ecrit: > sthibault: do you think this could be related to > https://github.com/linux-speakup/espeakup/pull/48 ? Possibly. Testing would give a definite answer. > > > It took me a couple of goes, and I lost speech entirely both times (not > > > sure why), but I got a trace. > > > > > > I'm not sure how helpful it is though. > > > > > > 0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > > > (gdb) bt > > > #0 0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > > > #1 0x7f9de46c4b33 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > > > #2 0x5605c505e734 in main (argc=, argv= > > out>) > > >at ../src/espeakup.c:229 To get useful information, the libc6-dbg package should be installed, and this should be used: thread apply all bt Samuel
Re: espeakup stops speaking bookworm arm64
sthibault: do you think this could be related to https://github.com/linux-speakup/espeakup/pull/48 ? (the reason for my guess: it is the only recent change within the espeak_thread function - and a buffer-full / wait condition feels like something that could occur semi-repeatably and could have edge cases) Although the change from that pull request is not included in the vanilla tarball of espeakup version 0.90 on GitHub, it is patched[1] into Debian. [1] - https://sources.debian.org/src/espeakup/1%3A0.90-13/debian/patches/flow_control/ On Wed, 20 Dec 2023 at 18:35, Frank Carmickle wrote: > > > > On Dec 20, 2023, at 13:21, Geoff Shang wrote: > > > > On Tue, 28 Nov 2023, James Addison wrote: > > > >> To do that, the first step is to enable a sources.list entry for debug > >> symbol packages, then to install the gdb and espeakup-dbgsym packages, > >> and then after the espeakup process stops speaking, to attach the gdb > >> debugger to locate where it got stuck by running: gdb > >> /usr/bin/espeakup > >> > >> If that works and you are provided with a (gdb) shell, you should be > >> able to type the single word 'bt' and press enter to get a backtrace, > >> and then copy and paste the results here. > > > > It took me a couple of goes, and I lost speech entirely both times (not > > sure why), but I got a trace. > > > > I'm not sure how helpful it is though. > > > > root@debian:~# gdb /usr/bin/espeakup 861 > > GNU gdb (Debian 13.1-3) 13.1 > > Copyright (C) 2023 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later > > <http://gnu.org/licenses/gpl.html> > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. > > Type "show copying" and "show warranty" for details. > > This GDB was configured as "x86_64-linux-gnu". > > Type "show configuration" for configuration details. > > For bug reporting instructions, please see: > > <https://www.gnu.org/software/gdb/bugs/>. > > Find the GDB manual and other documentation resources online at: > ><http://www.gnu.org/software/gdb/documentation/>. > > > > For help, type "help". > > Type "apropos word" to search for commands related to "word"... > > Reading symbols from /usr/bin/espeakup... > > Reading symbols from > > /usr/lib/debug/.build-id/76/62ad26e5f970e59309a544f3864db114aa389e.debug... > > Attaching to program: /usr/bin/espeakup, process 861 > > [New LWP 862] > > [New LWP 863] > > [New LWP 864] > > [New LWP 865] > > [New LWP 866] > > [Thread debugging using libthread_db enabled] > > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > > 0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > > (gdb) bt > > #0 0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > > #1 0x7f9de46c4b33 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > > #2 0x5605c505e734 in main (argc=, argv=) > >at ../src/espeakup.c:229 > > Thanks for working on this. > > Just to document, line 229 of espeakup.c is > > pthread_join(signal_thread_id, NULL); > > --FC >
Re: espeakup stops speaking bookworm arm64
> On Dec 20, 2023, at 13:21, Geoff Shang wrote: > > On Tue, 28 Nov 2023, James Addison wrote: > >> To do that, the first step is to enable a sources.list entry for debug >> symbol packages, then to install the gdb and espeakup-dbgsym packages, >> and then after the espeakup process stops speaking, to attach the gdb >> debugger to locate where it got stuck by running: gdb >> /usr/bin/espeakup >> >> If that works and you are provided with a (gdb) shell, you should be >> able to type the single word 'bt' and press enter to get a backtrace, >> and then copy and paste the results here. > > It took me a couple of goes, and I lost speech entirely both times (not sure > why), but I got a trace. > > I'm not sure how helpful it is though. > > root@debian:~# gdb /usr/bin/espeakup 861 > GNU gdb (Debian 13.1-3) 13.1 > Copyright (C) 2023 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "x86_64-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <https://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: ><http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from /usr/bin/espeakup... > Reading symbols from > /usr/lib/debug/.build-id/76/62ad26e5f970e59309a544f3864db114aa389e.debug... > Attaching to program: /usr/bin/espeakup, process 861 > [New LWP 862] > [New LWP 863] > [New LWP 864] > [New LWP 865] > [New LWP 866] > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > 0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > (gdb) bt > #0 0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > #1 0x7f9de46c4b33 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > #2 0x5605c505e734 in main (argc=, argv=) >at ../src/espeakup.c:229 Thanks for working on this. Just to document, line 229 of espeakup.c is pthread_join(signal_thread_id, NULL); --FC
Re: espeakup stops speaking bookworm arm64
On Tue, 28 Nov 2023, James Addison wrote: To do that, the first step is to enable a sources.list entry for debug symbol packages, then to install the gdb and espeakup-dbgsym packages, and then after the espeakup process stops speaking, to attach the gdb debugger to locate where it got stuck by running: gdb /usr/bin/espeakup If that works and you are provided with a (gdb) shell, you should be able to type the single word 'bt' and press enter to get a backtrace, and then copy and paste the results here. It took me a couple of goes, and I lost speech entirely both times (not sure why), but I got a trace. I'm not sure how helpful it is though. root@debian:~# gdb /usr/bin/espeakup 861 GNU gdb (Debian 13.1-3) 13.1 Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/bin/espeakup... Reading symbols from /usr/lib/debug/.build-id/76/62ad26e5f970e59309a544f3864db114aa389e.debug... Attaching to program: /usr/bin/espeakup, process 861 [New LWP 862] [New LWP 863] [New LWP 864] [New LWP 865] [New LWP 866] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x7f9de46bfda6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7f9de46c4b33 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x5605c505e734 in main (argc=, argv=) at ../src/espeakup.c:229 Cheers, Geoff.
Re: espeakup no sound
Hi Glen: Sometimes on a laptop running Voxin with Speakup, I had strange things where speech-dispatcher was already running. So I looked at running processes-and-manually killed everything related with speech, then launch speechd-up. Chime
espeakup no sound
Hello, I have Debian Bookworm 32 bit installed on my Asus, and I have audio when over SSH, but not from the keyboard. I do the login credentials with no speech, and I'm sure I'm logged in with the keyboard. I can do espeak-ng test and I hear it talk when done via SSH but not with the keyboard. I do speaker-test and the speaker test runs via SSH, but again, not from the keyboard. When I enter via SSH the following: espeakup It comes back with: 192 Can not work with the pid file /var/run/espeakup.pid: Permission denied Espeakup is already running! So then I do sudo - and enter the root password, and I'm in as root. Then I do espeakup and it says it is already running. spd-say test also speaks via SSH. When I boot up, it speaks a little bit at startup, but doesn't read all the information that espeakup normally speaks. It just goes silent from the keyboard. Does anyone have any ideas? Thanks. Glenn A man with a clock always knows what time it is. A man with two clocks is never sure. -- A derivative of Segal's law
Re: espeakup stops speaking bookworm arm64
On Mon, 27 Nov 2023 at 22:17, wrote: > > Hi all, > I don't know if my issue is the same as this or something different, but I am > experiencing Espeakup or Espeak crashing while using Vmware on one of the new > macs with the m2 processor. > > What url entries should Iput in my sources.list file to see if installing a > different package works better? That issue does seem similar, thanks Tom. I don't think there is known fix yet, but there are some debug packages that you could install if you have time to help track this down using gdb (a debugging tool). To do that, the first step is to enable a sources.list entry for debug symbol packages, then to install the gdb and espeakup-dbgsym packages, and then after the espeakup process stops speaking, to attach the gdb debugger to locate where it got stuck by running: gdb /usr/bin/espeakup If that works and you are provided with a (gdb) shell, you should be able to type the single word 'bt' and press enter to get a backtrace, and then copy and paste the results here. The sources.list entry I added for Debian bookworm has the URI http://deb.debian.org/debian-debug and the suite bookworm-debug, and only includes packages from main. More complete instructions are available at https://wiki.debian.org/HowToGetABacktrace - note that I don't think we should need to recompile any packages in this case, because debug symbol packages should be available on arm64. > -Original Message- > From: James Addison > Sent: Monday, November 27, 2023 3:04 PM > To: Geoff Shang > Cc: Frank Carmickle ; Debian Accessibility Team > ; ja...@jasonjgw.net > Subject: Re: espeakup stops speaking bookworm arm64 > > On Mon, 28 Aug 2023 at 10:46, Geoff Shang wrote: > > > > On Mon, 24 Apr 2023, James Addison wrote: > > > > > Working towards a better backtrace is a good recommendation. I'd also > > > like to mention that there are existing Debian bookworm debug symbol > > > packages available for both espeak and espeakup that can avoid the > > > need to recompile from source. > > > > > > The packages are named 'espeak-dbgsym' and 'espeakup-dbgsym' and can > > > be installed after enabling the bookworm-debug APT repository. > > > > I don't see espeakup-dbgsym in bookworm-debug. I do see espeak-dbgsym, > > however espeakup does not depend on espeak, it depends on libespeak, > > actually libespeak-ng1. There is also libespeak-ng1-dbgsym, but I'm not > > sure if espeakup would use it if I installed it. > > I find both espeak-dbgsym and espeakup-dbgsym available in the package > index today, after adding an apt sources.list entry for bookworm-debug > - perhaps it could be worth checking for them again? > > Finding a way to cause the behaviour where espeakup stops talking > would be useful to narrow in on the problem - I haven't been able to > replicate it so far. > > (with apologies for this multi-month delayed reply. I'll try not to > replicate that) > >
Re: espeakup stops speaking bookworm arm64
Hey Tom, > On Nov 27, 2023, at 17:17, > wrote: > > Hi all, > I don't know if my issue is the same as this or something different, but I am > experiencing Espeakup or Espeak crashing while using Vmware on one of the new > macs with the m2 processor. It's very much likely the same issue. I'm seeing on my m2 but with utm, which uses qemu for the virtualization. > What url entries should Iput in my sources.list file to see if installing a > different package works better? I don't think there are any. The question here is about weather or not the debug symbols packages help us trace the process when it locks up. I'll try again to run the debugger, but I don't think much has changed since I last check four months ago. --FC > > Tom > > > -Original Message- > From: James Addison > Sent: Monday, November 27, 2023 3:04 PM > To: Geoff Shang > Cc: Frank Carmickle ; Debian Accessibility Team > ; ja...@jasonjgw.net > Subject: Re: espeakup stops speaking bookworm arm64 > > On Mon, 28 Aug 2023 at 10:46, Geoff Shang wrote: >> >> On Mon, 24 Apr 2023, James Addison wrote: >> >>> Working towards a better backtrace is a good recommendation. I'd also >>> like to mention that there are existing Debian bookworm debug symbol >>> packages available for both espeak and espeakup that can avoid the >>> need to recompile from source. >>> >>> The packages are named 'espeak-dbgsym' and 'espeakup-dbgsym' and can >>> be installed after enabling the bookworm-debug APT repository. >> >> I don't see espeakup-dbgsym in bookworm-debug. I do see espeak-dbgsym, >> however espeakup does not depend on espeak, it depends on libespeak, >> actually libespeak-ng1. There is also libespeak-ng1-dbgsym, but I'm not >> sure if espeakup would use it if I installed it. > > I find both espeak-dbgsym and espeakup-dbgsym available in the package > index today, after adding an apt sources.list entry for bookworm-debug > - perhaps it could be worth checking for them again? > > Finding a way to cause the behaviour where espeakup stops talking > would be useful to narrow in on the problem - I haven't been able to > replicate it so far. > > (with apologies for this multi-month delayed reply. I'll try not to > replicate that) > >
RE: espeakup stops speaking bookworm arm64
Hi all, I don't know if my issue is the same as this or something different, but I am experiencing Espeakup or Espeak crashing while using Vmware on one of the new macs with the m2 processor. What url entries should Iput in my sources.list file to see if installing a different package works better? Tom -Original Message- From: James Addison Sent: Monday, November 27, 2023 3:04 PM To: Geoff Shang Cc: Frank Carmickle ; Debian Accessibility Team ; ja...@jasonjgw.net Subject: Re: espeakup stops speaking bookworm arm64 On Mon, 28 Aug 2023 at 10:46, Geoff Shang wrote: > > On Mon, 24 Apr 2023, James Addison wrote: > > > Working towards a better backtrace is a good recommendation. I'd also > > like to mention that there are existing Debian bookworm debug symbol > > packages available for both espeak and espeakup that can avoid the > > need to recompile from source. > > > > The packages are named 'espeak-dbgsym' and 'espeakup-dbgsym' and can > > be installed after enabling the bookworm-debug APT repository. > > I don't see espeakup-dbgsym in bookworm-debug. I do see espeak-dbgsym, > however espeakup does not depend on espeak, it depends on libespeak, > actually libespeak-ng1. There is also libespeak-ng1-dbgsym, but I'm not > sure if espeakup would use it if I installed it. I find both espeak-dbgsym and espeakup-dbgsym available in the package index today, after adding an apt sources.list entry for bookworm-debug - perhaps it could be worth checking for them again? Finding a way to cause the behaviour where espeakup stops talking would be useful to narrow in on the problem - I haven't been able to replicate it so far. (with apologies for this multi-month delayed reply. I'll try not to replicate that)
Re: espeakup stops speaking bookworm arm64
On Mon, 28 Aug 2023 at 10:46, Geoff Shang wrote: > > On Mon, 24 Apr 2023, James Addison wrote: > > > Working towards a better backtrace is a good recommendation. I'd also > > like to mention that there are existing Debian bookworm debug symbol > > packages available for both espeak and espeakup that can avoid the > > need to recompile from source. > > > > The packages are named 'espeak-dbgsym' and 'espeakup-dbgsym' and can > > be installed after enabling the bookworm-debug APT repository. > > I don't see espeakup-dbgsym in bookworm-debug. I do see espeak-dbgsym, > however espeakup does not depend on espeak, it depends on libespeak, > actually libespeak-ng1. There is also libespeak-ng1-dbgsym, but I'm not > sure if espeakup would use it if I installed it. I find both espeak-dbgsym and espeakup-dbgsym available in the package index today, after adding an apt sources.list entry for bookworm-debug - perhaps it could be worth checking for them again? Finding a way to cause the behaviour where espeakup stops talking would be useful to narrow in on the problem - I haven't been able to replicate it so far. (with apologies for this multi-month delayed reply. I'll try not to replicate that)
Re: espeakup stops speaking bookworm arm64
On Tue, 29 Aug 2023, Chevelle wrote: I'm using AMD64, but sometimes I can find the PID for pipewire-pulse with 'ps ax'. Then enter kill -SIGHUP Suddenly it will start working again. It might be worth a try. I'm not running pipewire. This is a console-only VM running under VMWare Player 17 on Windows. Cheers, Geoff.
Re: espeakup stops speaking bookworm arm64
I'm using AMD64, but sometimes I can find the PID for pipewire-pulse with 'ps ax'. Then enter kill -SIGHUP Suddenly it will start working again. It might be worth a try. On 8/28/23 05:46, Geoff Shang wrote: On Mon, 24 Apr 2023, James Addison wrote: Working towards a better backtrace is a good recommendation. I'd also like to mention that there are existing Debian bookworm debug symbol packages available for both espeak and espeakup that can avoid the need to recompile from source. The packages are named 'espeak-dbgsym' and 'espeakup-dbgsym' and can be installed after enabling the bookworm-debug APT repository. I don't see espeakup-dbgsym in bookworm-debug. I do see espeak-dbgsym, however espeakup does not depend on espeak, it depends on libespeak, actually libespeak-ng1. There is also libespeak-ng1-dbgsym, but I'm not sure if espeakup would use it if I installed it. Cheers, Geoff.
Re: espeakup stops speaking bookworm arm64
On Mon, 24 Apr 2023, James Addison wrote: Working towards a better backtrace is a good recommendation. I'd also like to mention that there are existing Debian bookworm debug symbol packages available for both espeak and espeakup that can avoid the need to recompile from source. The packages are named 'espeak-dbgsym' and 'espeakup-dbgsym' and can be installed after enabling the bookworm-debug APT repository. I don't see espeakup-dbgsym in bookworm-debug. I do see espeak-dbgsym, however espeakup does not depend on espeak, it depends on libespeak, actually libespeak-ng1. There is also libespeak-ng1-dbgsym, but I'm not sure if espeakup would use it if I installed it. Cheers, Geoff.
Re: espeakup stops speaking bookworm arm64
I have the AMD64 build of bookworm, but I have had it stop speaking. Sometimes if I have a graphical session running, then switch to a speakup console, it is very slow to respond. I wrote a simple bash script like this: #!/usr/bin/bash sleep 5 ls I start that in the terminal with ORCA running then switch consoles to another session. With that I can get some errors in the 'espeakup' debug log like this: error: Device or resource busy ALSA lib pcm_dmix.c:999:(snd_pcm_dmix_open) unable to open slave error: Device or resource busy ALSA lib pcm_dmix.c:999:(snd_pcm_dmix_open) unable to open slave error: Device or resource busy ALSA lib pcm_dmix.c:999:(snd_pcm_dmix_open) unable to open slave error: Device or resource busy Also if it is talking and you type something in the console you are in, it can't stop the speech. Maybe I'm expecting to much, I'm not sure how it is designed to work. Not sure if that helps. On 8/18/23 12:39, Frank Carmickle wrote: Greetings, I've been living with this for the last sixish months, and it's annoying. I have a console where I can just up arrow and hit enter for `killall -1 espeakup` I would love to see this get fixed but I've gotten nowhere with debugging it. I haven't tried Sam's recommendation of having a middle layer of pulseaudio or pipewire to keep the audio buffer always full with silence when it's not speaking. I spent so much time trying to get a working machine before, that I've not wanted to go back to work on it again for a bit. I'll probably get to it when the kids go back to school in a few weeks time. I'll let you know if I find it to be of help. --FC On Aug 17, 2023, at 13:48, Geoff Shang wrote: Hello, I just updated to Bookworm on my work VM running under VMWare 17 under Windows 11 and am experiencing the same problem. This was not happening under Bullseye. The only other thing that I can add to what has already been described in this thread is that using conventional Debian methods to stop the espeakup process takes a long time. Running espeakup in debug mode doesn't print anything to the console, and when I lose speech, I have to press control-backslash to kill it (control-c doesn't work). I've only just seen the suggestion to test with the debug versions, which I will try at some point soon. I'm running just in the console, no desktop environments. BTW: I was just proofing this message and it died. I was cursoring down through this email, so I wasn't reviewing by character this time. Cheers, Geoff.
Re: espeakup stops speaking bookworm arm64
Greetings, I've been living with this for the last sixish months, and it's annoying. I have a console where I can just up arrow and hit enter for `killall -1 espeakup` I would love to see this get fixed but I've gotten nowhere with debugging it. I haven't tried Sam's recommendation of having a middle layer of pulseaudio or pipewire to keep the audio buffer always full with silence when it's not speaking. I spent so much time trying to get a working machine before, that I've not wanted to go back to work on it again for a bit. I'll probably get to it when the kids go back to school in a few weeks time. I'll let you know if I find it to be of help. --FC > On Aug 17, 2023, at 13:48, Geoff Shang wrote: > > Hello, > > I just updated to Bookworm on my work VM running under VMWare 17 under > Windows 11 and am experiencing the same problem. > > This was not happening under Bullseye. > > The only other thing that I can add to what has already been described in > this thread is that using conventional Debian methods to stop the espeakup > process takes a long time. Running espeakup in debug mode doesn't print > anything to the console, and when I lose speech, I have to press > control-backslash to kill it (control-c doesn't work). > > I've only just seen the suggestion to test with the debug versions, which I > will try at some point soon. > > I'm running just in the console, no desktop environments. > > BTW: I was just proofing this message and it died. I was cursoring down > through this email, so I wasn't reviewing by character this time. > > Cheers, > Geoff. > > >
Re: espeakup stops speaking bookworm arm64
Hello, I just updated to Bookworm on my work VM running under VMWare 17 under Windows 11 and am experiencing the same problem. This was not happening under Bullseye. The only other thing that I can add to what has already been described in this thread is that using conventional Debian methods to stop the espeakup process takes a long time. Running espeakup in debug mode doesn't print anything to the console, and when I lose speech, I have to press control-backslash to kill it (control-c doesn't work). I've only just seen the suggestion to test with the debug versions, which I will try at some point soon. I'm running just in the console, no desktop environments. BTW: I was just proofing this message and it died. I was cursoring down through this email, so I wasn't reviewing by character this time. Cheers, Geoff.
Re: Choppy speech when using espeak and espeakup on a Raspberry Pi
Hi, So... This is a bit embarrasing. As you might know, Raspberry Pi OS changes its major version some months after Debian, as I'm writing this it hasn't changed its major version yet. But you can update its packages' repositories to get them from the next version. So, after doing a backup I did so and... no more choppy espeak nor espeakup. So, either wait, or change bullseye for bookworm everywhere in /etc/apt/sources.list.d/raspi.list and /etc/apt/sources.list . An important note, though: now espeak-ng refuses to say anything if I use it from the command line if espeakup is running first (killing espeakup then restarting it lets me use them at the same time). Any guidance to fix this would be appreciated, though I must admit this is less important to me than the choppy speech (which, as I said, got fixed after updating). Thanks, Sukil El 07/08/2023 a las 18:47, K0LNY escribió: I remember that problem in windows. I installed eSpeak to use with Jaws and it was really choppy. I didn't know it had gotten fixed. The choppy speech in RaspberryPI is pretty bad. I don't think the problem occurs in Arch, such as Stormux. Glenn - Original Message - From: "Sukil Etxenike arizaleta" To: Sent: Monday, August 7, 2023 1:21 AM Subject: Re: Choppy speech when using espeak and espeakup on a Raspberry Pi Hello, There was an issue with stuttering on Windows: <https://github.com/espeak-ng/espeak-ng/issues/1190> which got fixed (but no new versions were released afterwards). I created an issue, it is at <https://github.com/espeak-ng/espeak-ng/issues/1781>. Thanks, Sukil El 07/08/2023 a las 1:22, Samuel Thibault escribió: Hello, Sukil Etxenike arizaleta, le sam. 05 août 2023 19:10:17 +0200, a ecrit: I am experiencing choppy speech when running espeakup and also when running espeak on its own, but not when generating wave files and playing them with aplay. I'd say this should be discussed with upstream espeak-ng, https://github.com/espeak-ng/espeak-ng/issues Samuel
Re: Choppy speech when using espeak and espeakup on a Raspberry Pi
I remember that problem in windows. I installed eSpeak to use with Jaws and it was really choppy. I didn't know it had gotten fixed. The choppy speech in RaspberryPI is pretty bad. I don't think the problem occurs in Arch, such as Stormux. Glenn - Original Message - From: "Sukil Etxenike arizaleta" To: Sent: Monday, August 7, 2023 1:21 AM Subject: Re: Choppy speech when using espeak and espeakup on a Raspberry Pi Hello, There was an issue with stuttering on Windows: <https://github.com/espeak-ng/espeak-ng/issues/1190> which got fixed (but no new versions were released afterwards). I created an issue, it is at <https://github.com/espeak-ng/espeak-ng/issues/1781>. Thanks, Sukil El 07/08/2023 a las 1:22, Samuel Thibault escribió: > Hello, > > Sukil Etxenike arizaleta, le sam. 05 août 2023 19:10:17 +0200, a ecrit: >> I am experiencing choppy speech when running espeakup and also when >> running espeak on its own, but not when generating wave files and >> playing them with aplay. > I'd say this should be discussed with upstream espeak-ng, > https://github.com/espeak-ng/espeak-ng/issues > > Samuel
Re: Choppy speech when using espeak and espeakup on a Raspberry Pi
Hello, There was an issue with stuttering on Windows: <https://github.com/espeak-ng/espeak-ng/issues/1190> which got fixed (but no new versions were released afterwards). I created an issue, it is at <https://github.com/espeak-ng/espeak-ng/issues/1781>. Thanks, Sukil El 07/08/2023 a las 1:22, Samuel Thibault escribió: Hello, Sukil Etxenike arizaleta, le sam. 05 août 2023 19:10:17 +0200, a ecrit: I am experiencing choppy speech when running espeakup and also when running espeak on its own, but not when generating wave files and playing them with aplay. I'd say this should be discussed with upstream espeak-ng, https://github.com/espeak-ng/espeak-ng/issues Samuel
Re: Choppy speech when using espeak and espeakup on a Raspberry Pi
Hello, Sukil Etxenike arizaleta, le sam. 05 août 2023 19:10:17 +0200, a ecrit: > I am experiencing choppy speech when running espeakup and also when > running espeak on its own, but not when generating wave files and > playing them with aplay. I'd say this should be discussed with upstream espeak-ng, https://github.com/espeak-ng/espeak-ng/issues Samuel
Choppy speech when using espeak and espeakup on a Raspberry Pi
Hello, First, sorry if this is not the right place to ask this, please direct me there if that's not the case. Also, please CC me on your replies if you don't mind (I will check the archives regardless). I am running espeakup on a Raspberry Pi 4B runningrunning bullseye (the lite version with no desktop). I am experiencing choppy speech when running espeakup and also when running espeak on its own, but not when generating wave files and playing them with aplay. Sadly I don't have any more information, but if you want me to test anything, please provide steps and I will gladly follow them. Thanks a lot, Sukil P. S.: Sorry if duplicate posting (to pkg-a11y) is frowned upon, I did so this morning.
Re: espeakup stops speaking bookworm arm64
On Sun, 30 Apr 2023 at 01:10, James Addison wrote: > > I don't have much to (bug)report here yet, but have begun using > espeakup as a screen reader via Orca in GNOME. CPU usage on the > machine seemed relatively high, and at times text input became > unresponsive (both in-browser, where both window scrolling and > input-field text entry became unreliable). The espeakup process also > segfaulted once (this was over approximately 8 hours or so of > continuous usage). A missing ingredient from that soup of words: "(both in-browser, where both window scrolling and input-field text entry became unreliable, _and also within a gnome-terminal session_)." (I think it's important to include that detail, because it suggests to me that the cause of the high-resource-usage and/or input interaction problems is not specific to one desktop application, and could be an issue with Debian's espeakup/espeak-ng, and/or and their interaction with the GNOME desktop. CPU usage decreases to normal levels and expected input behaviour is restored after screenreading is turned off)
Re: espeakup stops speaking bookworm arm64
On Tue, 25 Apr 2023 at 10:20, James Addison wrote: > > On Mon, 24 Apr 2023 at 23:38, James Addison wrote: > > > > On Apr 20, 2023, at 08:47:11, Jason White wrote: > > > > > > Perhaps the following would also be worth trying: > > > > > > Rebuild Espeakup with compiler optimizations turned off and with debug > > > symbols enabled. This might produce a beter gdb backtrace if you connect > > > to the process when it's failing to generate output. You might also need > > > to rebuild Espeak, though. > > > > Working towards a better backtrace is a good recommendation. I'd also > > like to mention that there are existing Debian bookworm debug symbol > > packages available for both espeak and espeakup that can avoid the > > need to recompile from source. > > As a follow-up and partly for my own future reference: there is good > documentation about retrieving backtraces on Debian systems at > https://wiki.debian.org/HowToGetABacktrace I don't have much to (bug)report here yet, but have begun using espeakup as a screen reader via Orca in GNOME. CPU usage on the machine seemed relatively high, and at times text input became unresponsive (both in-browser, where both window scrolling and input-field text entry became unreliable). The espeakup process also segfaulted once (this was over approximately 8 hours or so of continuous usage).
Re: espeakup stops speaking bookworm arm64
On Mon, 24 Apr 2023 at 23:38, James Addison wrote: > > On Apr 20, 2023, at 08:47:11, Jason White wrote: > > > > Perhaps the following would also be worth trying: > > > > Rebuild Espeakup with compiler optimizations turned off and with debug > > symbols enabled. This might produce a beter gdb backtrace if you connect to > > the process when it's failing to generate output. You might also need to > > rebuild Espeak, though. > > Working towards a better backtrace is a good recommendation. I'd also > like to mention that there are existing Debian bookworm debug symbol > packages available for both espeak and espeakup that can avoid the > need to recompile from source. As a follow-up and partly for my own future reference: there is good documentation about retrieving backtraces on Debian systems at https://wiki.debian.org/HowToGetABacktrace
Re: espeakup stops speaking bookworm arm64
On Apr 20, 2023, at 08:47:11, Jason White wrote: > > Perhaps the following would also be worth trying: > > Rebuild Espeakup with compiler optimizations turned off and with debug > symbols enabled. This might produce a beter gdb backtrace if you connect to > the process when it's failing to generate output. You might also need to > rebuild Espeak, though. Working towards a better backtrace is a good recommendation. I'd also like to mention that there are existing Debian bookworm debug symbol packages available for both espeak and espeakup that can avoid the need to recompile from source. The packages are named 'espeak-dbgsym' and 'espeakup-dbgsym' and can be installed after enabling the bookworm-debug APT repository. To do that on my system, I opened the APT sources.list file, duplicated the entry containing suite 'bookworm' for component 'main', and then edited the duplicate to contain suite 'bookworm-debug' and to replace URL ending '/debian' with '/debian-debug' instead. (during the upgrade to bookworm, I converted the format of my APT sources list, so I won't share the contents in this thread yet because its format may be different to each of yours, a possible distraction, but please let me know if it would be useful as a reference) I've installed the packages and debug symbol packages on my machine, so as we gather more ideas about how to make the problem reappear, I'll be glad to join in tracing it down.
Re: espeakup stops speaking bookworm arm64
Perhaps the following would also be worth trying: Rebuild Espeakup with compiler optimizations turned off and with debug symbols enabled. This might produce a beter gdb backtrace if you connect to the process when it's failing to generate output. You might also need to rebuild Espeak, though. On 15/4/23 10:55, Frank Carmickle wrote: On Apr 15, 2023, at 08:25, James Addison wrote: If you're using systemd to manage services on those hosts: does the system journal indicate any failures/restarts of the espeakup service? No. Systemd only notices when I send the HUP signal. Even when I run it in the foreground, and the speech stops, it reports nothing and continues operation. --FC
Re: espeakup stops speaking bookworm arm64
On Apr 15, 2023, at 08:25, James Addison wrote: > > > If you're using systemd to manage services on those hosts: does the > system journal indicate any failures/restarts of the espeakup service? No. Systemd only notices when I send the HUP signal. Even when I run it in the foreground, and the speech stops, it reports nothing and continues operation. --FC
Re: espeakup stops speaking bookworm arm64
On Tue, 11 Apr 2023 at 18:27, Frank Carmickle wrote: > > On Apr 11, 2023, at 13:19, James Addison wrote: > > That could be a useful clue. Which of those three systems, if any, > > are multi-processor? > > I suspected such a thing and so today I have been running the qemu arm64 > system with a single core. Quite unfortunately it still stops speaking. All > of these systems are multiprocessor except for todays exercise with one core. Hm, ok - well, it's good to know that the problem appears regardless of single-core / multi-core. If you're using systemd to manage services on those hosts: does the system journal indicate any failures/restarts of the espeakup service?
Re: espeakup stops speaking bookworm arm64
> "Frank" == Frank Carmickle writes: >> You could play around with adding/subtracting pulseaudio/pipewire >> within the guest and different approaches for how the emulator >> talks to the host OS sound stack to explore whether this is the >> case. Frank> I have as minimal a setup as possible, no pulseaudio or Frank> pipewire. Alsa reports the card as running at 48k and every Frank> time the qemu starts the system it sets the guest to Frank> 44.1k. We know then that qemu is resampling. I did start some Frank> discussion about this on the qemu list. Minimal is not always good here. Something like pipewire or pulse is very likely to provide full buffers and to provide silence if there's nothing to play until the device is suspended. Speech synthesizers are likely to just let the card underrun if they have nothing to play. I don't have specific recommendations on looking at interrupts. If I wanted to test this hypothesis I'd write a small C program to try and do what I thought espeak was doing and see if I could reproduce that way. That's kind of a pain, so I'd be more likely to see if I could get the problem to go away by introducing pulse or pipewire, or adding or removing dmix at the alsa level (although it's been a number of years and I don't remember off the top of my head how to do that.) --Sam
Re: espeakup stops speaking bookworm arm64
On Apr 13, 2023, at 14:26, Sam Hartman wrote: > >> "Frank" == Frank Carmickle writes: > >Frank> Good day all, I'm pretty certain now that speech stops when >Frank> doing screen review by character. > >Frank> Does anyone know what would be different about this that >Frank> would make this happen? > > This is just a guess, but you might run into trouble if the amount of > speech produced by one character is less than some sound fragment size. > I.E. something is setting up to deliver interrupts when a buffer gets > empty, but the buffer never gets full enough to trigger that. > So a bug in the sound stack within the vm or a bug in the emulated sound > card or a bug in the sound stack in the host OS > or a bug in how the emulator interacts with the sound stack in the host > os. > By sound stack I include things like pulseaudio and pipewire. Any recommendations on looking at interrupts? > You could play around with adding/subtracting pulseaudio/pipewire within > the guest and different approaches for how the emulator talks to the > host OS sound stack to explore whether this is the case. I have as minimal a setup as possible, no pulseaudio or pipewire. Alsa reports the card as running at 48k and every time the qemu starts the system it sets the guest to 44.1k. We know then that qemu is resampling. I did start some discussion about this on the qemu list. Any tips on debugging alsa and the interface from espeak to it, and kernel to the emulated audio hardware? > I want to stress that this is only my guess, although I have run into > such problems over the years. I'm guessing the problem is somewhere other than the emulated hardware to the kernel, as I see this behavior under the vmware hypervisor on x8664 as well as qemu arm64. When I can get some other hardware spun up, I can try qemu on x8664 with Linux as the host instead of macOS. Thanks for the discussion. --FC
Re: espeakup stops speaking bookworm arm64
> "Frank" == Frank Carmickle writes: Frank> Good day all, I'm pretty certain now that speech stops when Frank> doing screen review by character. Frank> Does anyone know what would be different about this that Frank> would make this happen? This is just a guess, but you might run into trouble if the amount of speech produced by one character is less than some sound fragment size. I.E. something is setting up to deliver interrupts when a buffer gets empty, but the buffer never gets full enough to trigger that. So a bug in the sound stack within the vm or a bug in the emulated sound card or a bug in the sound stack in the host OS or a bug in how the emulator interacts with the sound stack in the host os. By sound stack I include things like pulseaudio and pipewire. You could play around with adding/subtracting pulseaudio/pipewire within the guest and different approaches for how the emulator talks to the host OS sound stack to explore whether this is the case. I want to stress that this is only my guess, although I have run into such problems over the years.
Re: espeakup stops speaking bookworm arm64
Good day all, I'm pretty certain now that speech stops when doing screen review by character. Does anyone know what would be different about this that would make this happen? I am on the latest, 0.90-13. Thanks much, --FC
Re: espeakup stops speaking bookworm arm64
On Mon, 10 Apr 2023 at 21:07, Frank Carmickle wrote: > > On Mar 30, 2023, at 10:49, James Addison wrote: > > > > Yep, bugs with unpredictable timing can be particularly hard to track > > down. I noticed some references to process threads in one of your > > previous messages (the acronym nptl for native posix thread library) > > and also in the source code: that occurs to me as a possible area to > > investigate, although I don't have clear suggestions on how we could > > pinpoint thread-related timing issues. > > > I have yet to correlate this to anything. I've begun looking in to the clock > that qemu provides. It seems as though there aren't any hardware clocks > accessible inside the VM on qemu hosted by macOS on aarch64. I'll report back. Ok, thank you. > I was seeing the on vmware on amd64 also. > > I have a bullseye machine running on bare metal that I haven't experienced > this issue with as of yet. That could be a useful clue. Which of those three systems, if any, are multi-processor?
Re: espeakup stops speaking bookworm arm64
On Apr 11, 2023, at 13:19, James Addison wrote: > That could be a useful clue. Which of those three systems, if any, > are multi-processor? I suspected such a thing and so today I have been running the qemu arm64 system with a single core. Quite unfortunately it still stops speaking. All of these systems are multiprocessor except for todays exercise with one core. --FC
Re: espeakup stops speaking bookworm arm64
On Mar 30, 2023, at 10:49, James Addison wrote: > > Yep, bugs with unpredictable timing can be particularly hard to track > down. I noticed some references to process threads in one of your > previous messages (the acronym nptl for native posix thread library) > and also in the source code: that occurs to me as a possible area to > investigate, although I don't have clear suggestions on how we could > pinpoint thread-related timing issues. I have yet to correlate this to anything. I've begun looking in to the clock that qemu provides. It seems as though there aren't any hardware clocks accessible inside the VM on qemu hosted by macOS on aarch64. I'll report back. I was seeing the on vmware on amd64 also. I have a bullseye machine running on bare metal that I haven't experienced this issue with as of yet. --FC
Re: espeakup stops speaking bookworm arm64
On Wed, 29 Mar 2023 at 20:14, Frank Carmickle wrote: > I guess you missed my followup message that it still does stop speaking. I'm > trying to notice as much as I can about the environment when it stops > speaking. I did read that message - it seemed possible to me that configuring a language could have altered the program's behaviour and reduced either the number of errors, or their frequency. > Maybe it's that I haven't tried the default language though. How would I find > that? I'm not sure yet, but I do see some "udeb" scripts that might be relevant and should be found in the following directory: /usr/share/espeakup-udeb/ And in package version 1:0.90-11, I see a default voice of "en" in the udeb start script, in at least three places. There are some more recent package versions available, if you'd like to try an upgrade. It would be nice to figure out what the error's cause is/was, though. > I do find that it stops speaking mostly when I am navigating by character. It > seems as though navigating by character a bit slower is mostly when it > happens, but not all the time. > > It's super annoying that it can quit after a minute of use or many hours. Yep, bugs with unpredictable timing can be particularly hard to track down. I noticed some references to process threads in one of your previous messages (the acronym nptl for native posix thread library) and also in the source code: that occurs to me as a possible area to investigate, although I don't have clear suggestions on how we could pinpoint thread-related timing issues.
Re: espeakup stops speaking bookworm arm64
On Mar 29, 2023, at 17:55, James Addison wrote: > > Ok, that's cautiously promising. I guess you missed my followup message that it still does stop speaking. I'm trying to notice as much as I can about the environment when it stops speaking. I do find that it stops speaking mostly when I am navigating by character. It seems as though navigating by character a bit slower is mostly when it happens, but not all the time. It's super annoying that it can quit after a minute of use or many hours. Thanks, --FC
Re: espeakup stops speaking bookworm arm64
Ok, that's cautiously promising. The next suggestion is maybe a bit annoying: try undoing or commenting-out the language selection and checking whether the previous error-prone behaviour returns. I haven't been able to figure out why choosing a language in the config file would make a difference yet, but if we can confirm that it definitely does, then that's a useful clue. On Wed, Mar 29, 2023, 20:14 Frank Carmickle wrote: > On Mar 29, 2023, at 14:17, Frank Carmickle wrote: > > That appears to be a very good question, as when I specify a language at > all it doesn't seem to stop speaking. I hadn't even realized that the > system didn't have a value in the config, /etc/default/espeakup. I'll keep > pounding on it. As of the last few hours, I can not make it stop speaking > once I have a language set. Maybe it's that I haven't tried the default > language though. How would I find that? > > Spoke too soon . That time it took a very long time to replicate. > > Next? > > Thanks so much. > --FC > >
Re: espeakup stops speaking bookworm arm64
On Mar 29, 2023, at 14:17, Frank Carmickle wrote: > That appears to be a very good question, as when I specify a language at all > it doesn't seem to stop speaking. I hadn't even realized that the system > didn't have a value in the config, /etc/default/espeakup. I'll keep pounding > on it. As of the last few hours, I can not make it stop speaking once I have > a language set. Maybe it's that I haven't tried the default language though. > How would I find that? Spoke too soon . That time it took a very long time to replicate. Next? Thanks so much. --FC
Re: espeakup stops speaking bookworm arm64
On Mar 29, 2023, at 10:23, James Addison wrote: > > Ok. I'm not sure what to suggest in terms of build changes, so I'm wondering > about other command-line options before learning more about the build. > > Does the problem occur when using different voices and languages? That appears to be a very good question, as when I specify a language at all it doesn't seem to stop speaking. I hadn't even realized that the system didn't have a value in the config, /etc/default/espeakup. I'll keep pounding on it. As of the last few hours, I can not make it stop speaking once I have a language set. Maybe it's that I haven't tried the default language though. How would I find that? Thanks much. --FC
Re: espeakup stops speaking bookworm arm64
Ok. I'm not sure what to suggest in terms of build changes, so I'm wondering about other command-line options before learning more about the build. Does the problem occur when using different voices and languages? On Wed, Mar 29, 2023, 15:12 Frank Carmickle wrote: > Hello James, > > Thanks for this. It does not print any information when speaking stops. > It does print that it received the hangup signal, which is what I sent to > kill the process. > > What shall we add to a build to gain more insight? > > Thank you, > --FC > > > > > > > On Mar 29, 2023, at 09:52, James Addison wrote: > > > > On Mon, 20 Mar 2023 16:31:54 -0400, Frank wrote: > >> I've reported this before, and I believe we had a fix for it. I just > saw it happen again. This time it's bookworm arm64 . I can't remember what > info was needed to track this down. Let me know what I can do please. > > > > Hi Frank, > > > > If you run the espeakup command with the debug flag ( --debug ) does > > it produce any additional information before the process exits? > > > > Thanks, > > James > >
Re: espeakup stops speaking bookworm arm64
Hello James, Thanks for this. It does not print any information when speaking stops. It does print that it received the hangup signal, which is what I sent to kill the process. What shall we add to a build to gain more insight? Thank you, --FC > On Mar 29, 2023, at 09:52, James Addison wrote: > > On Mon, 20 Mar 2023 16:31:54 -0400, Frank wrote: >> I've reported this before, and I believe we had a fix for it. I just saw it >> happen again. This time it's bookworm arm64 . I can't remember what info was >> needed to track this down. Let me know what I can do please. > > Hi Frank, > > If you run the espeakup command with the debug flag ( --debug ) does > it produce any additional information before the process exits? > > Thanks, > James
Re: espeakup stops speaking bookworm arm64
On Mon, 20 Mar 2023 16:31:54 -0400, Frank wrote: > I've reported this before, and I believe we had a fix for it. I just saw it > happen again. This time it's bookworm arm64 . I can't remember what info was > needed to track this down. Let me know what I can do please. Hi Frank, If you run the espeakup command with the debug flag ( --debug ) does it produce any additional information before the process exits? Thanks, James
Re: espeakup stops speaking version 1:0.90-11
On 25/3/23 14:21, Frank Carmickle wrote: Does anyone have any ideas? This isn't the answer you're looking for, but you could try making the switch to Fenrir instead. It's packaged in Debian.
Re: espeakup stops speaking version 1:0.90-11
On Mar 25, 2023, at 13:45, Jason White wrote: > > On 25/3/23 13:27, Frank Carmickle wrote: >> That's nasty. What happens if you run Espeakup within gdb from the beginning? >> It doesn't speak at all. I may just not know what I'm doing in the debugger. > Did you use the run command to start execution of the program once it was > loaded in the debugger? You can supply any desired command line options. Thank you for spelling that out for me. I thought I needed to tell it to execute somehow. Quite unfortunately this is what happens. Reading symbols from /usr/bin/espeakup... Reading symbols from /usr/lib/debug/.build-id/2c/a5375523b29da3b9abcab61d402b5d1d074942.debug... (gdb) run Starting program: /usr/bin/espeakup --default-voice=en [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1". /build/gdb-yCDzia/gdb-13.1/gdb/thread.c:85: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. - Backtrace - 0xc8be9b9b ??? 0xc8f2cefb ??? 0xc8f2d0e3 ??? 0xc90d4873 ??? 0xc8ee6ebb ??? 0xc8e3f49b ??? 0xc8b3a2bf ??? 0xc8ee1a37 ??? 0xc8ee1f47 ??? 0xc8ee1ff7 ??? 0xc8de82d7 ??? 0x7a885387 _td_fetch_value ./nptl_db/fetch-value.c:115 0x7a88230f td_ta_map_lwp2thr ./nptl_db/td_ta_map_lwp2thr.c:194 0xc8d77d8f ??? 0xc8d79347 ??? 0xc8ee3e73 ??? 0xc8d3a8a7 ??? 0xc8d4b82f ??? 0xc90d4d03 ??? 0xc90d57f7 ??? 0xc8d89d0f ??? 0xc8d8b737 ??? 0xc8b31183 ??? 0x8026777f __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 0x80267857 __libc_start_main_impl ../csu/libc-start.c:381 0xc8b373af ??? 0x ??? - /build/gdb-yCDzia/gdb-13.1/gdb/thread.c:85: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Copying the speakup mailing list also, as I think William might be hanging out there too. The back story is that I'm having an issue where espeakup stops speaking. It appears to do so completely randomly. I'm seeing it on multiple installations, arm64 now. I have seen this before on amd64 also. I've been using it under both vmware Fusion, amd64, and now qemu arm64. I will do some testing on bare metal to see if there's any impact. Does anyone have any ideas? Thanks all, --FC
Re: espeakup stops speaking version 1:0.90-11
On 25/3/23 13:27, Frank Carmickle wrote: That's nasty. What happens if you run Espeakup within gdb from the beginning? It doesn't speak at all. I may just not know what I'm doing in the debugger. Did you use the run command to start execution of the program once it was loaded in the debugger? You can supply any desired command line options.
Re: espeakup stops speaking version 1:0.90-11
On Mar 22, 2023, at 18:12, Jason White wrote: > > > On 22/3/23 15:33, Frank Carmickle wrote: >> Here's the output inside gdb after espeakup stops talking. >> >> /build/gdb-yCDzia/gdb-13.1/gdb/thread.c:85: internal-error: inferior_thread: >> Assertion `current_thread_ != nullptr' failed. >> A problem internal to GDB has been detected, >> further debugging may prove unreliable. > > That's nasty. What happens if you run Espeakup within gdb from the beginning? It doesn't speak at all. I may just not know what I'm doing in the debugger. Anyone else have any recommendations? Thank you, --FC
Re: espeakup stops speaking version 1:0.90-11
On 22/3/23 15:33, Frank Carmickle wrote: Here's the output inside gdb after espeakup stops talking. /build/gdb-yCDzia/gdb-13.1/gdb/thread.c:85: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. That's nasty. What happens if you run Espeakup within gdb from the beginning? Someone else will probably have better advice here.
Re: espeakup stops speaking version 1:0.90-11
Greetings Jason et al. On Mar 21, 2023, at 11:28, Jason White wrote: > Can you log in remotely and attach gdb to the espeak process when it's not > speaking but (obviously) before you kill it? Then obtain a backtrace. You > might need to install debug symbols for espeakup. Debian has separate > packages for those. > > The syntax would be > gdb /usr/bin/espeakup Here's the output inside gdb after espeakup stops talking. /build/gdb-yCDzia/gdb-13.1/gdb/thread.c:85: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. - Backtrace - 0xb9c39b9b ??? 0xb9f7cefb ??? 0xb9f7d0e3 ??? 0xba124873 ??? 0xb9f36ebb ??? 0xb9e8f49b ??? 0xb9b8a2bf ??? 0xb9f31a37 ??? 0xb9f31f47 ??? 0xb9f31ff7 ??? 0xb9e382d7 ??? 0xa6b35387 _td_fetch_value ./nptl_db/fetch-value.c:115 0xa6b3230f td_ta_map_lwp2thr ./nptl_db/td_ta_map_lwp2thr.c:194 0xb9dc7d8f ??? 0xb9dc9347 ??? 0xb9f33e73 ??? 0xb9d9081f ??? 0xb9d9c033 ??? 0xba124d03 ??? 0xba1257f7 ??? 0xb9f40787 ??? 0xb9dd8dd3 ??? 0xb9ddb513 ??? 0xb9ddb733 ??? 0xb9b81183 ??? 0xb0de777f __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 0xb0de7857 __libc_start_main_impl ../csu/libc-start.c:381 0xb9b873af ??? 0x ??? - Do we now need to debug the debugger? Thanks all, --FC
Re: espeakup stops speaking version 1:0.90-11
On 21/3/23 10:38, Frank Carmickle wrote: Should I run this inside gdb, or should we put in some print statements? Please let me know what I can do to help track this bugger down! Can you log in remotely and attach gdb to the espeak process when it's not speaking but (obviously) before you kill it? Then obtain a backtrace. You might need to install debug symbols for espeakup. Debian has separate packages for those. The syntax would be gdb /usr/bin/espeakup
Re: espeakup stops speaking version 1:0.90-11
Reviving this old thread, as I am seeing espeakup stopping speech output. I am not seeing this in conjunction with the buffer overlaps, however, the current setup I have has such small buffers that I may not be able to notice. I am running current bookworm, espeakup 1:0.90-12, kernel 6.1.0-6-arm64 (6.1.15-1). This is running under qemu 7.1.0 compiled by mac ports. I first reported this on amd64 under vmware fusion 11.5.7. Sometimes it stops speaking after a minute or two of use. Other times it takes ten minutes or so. Sometimes it quits while quickly running through lots of output by word. This last time it stopped speaking, I was reading a letter at a time, slightly faster than one per second. If I killall -1 espeakup, it will speak some items left in a buffer, right away. Should I run this inside gdb, or should we put in some print statements? Please let me know what I can do to help track this bugger down! Thanks, --FC > On Oct 28, 2022, at 14:51, Frank Carmickle wrote: > > Hi again, > >> On Oct 28, 2022, at 11:16 AM, Samuel Thibault wrote: >> >> Frank Carmickle, le ven. 28 oct. 2022 11:03:58 -0400, a ecrit: >>> I have been taking newer kernels. >> >> Kernel device drivers introduce buffering, so it can be useful to >> investigate if it's a new kernel that introduced the regression. > > I couldn't get my hands on a binary for 5.17.x. I booted the current bullseye > kernel, 5.10.149-2. I still had the problem, although in a different way. > This time the speech stopped before the buffer overwriting. As soon as I > restarted speech the buffer overwriting was happening. I'm guessing they are > still very much related but once it happens you can get an immediate stopping > of speech or you can get the buffer overwriting first. > > I'll keep poking away at this. If you have any other ideas, toss them my way. > I'll try them all. > > I'm booted on to 6.0.2 again. > > > --FC >
Re: espeakup stops speaking bookworm arm64
Hello, Frank Carmickle, le lun. 20 mars 2023 16:31:54 -0400, a ecrit: > I've reported this before, and I believe we had a fix for it. I don't remember what issue you refer to. Samuel
espeakup stops speaking bookworm arm64
Hello all, I've reported this before, and I believe we had a fix for it. I just saw it happen again. This time it's bookworm arm64 . I can't remember what info was needed to track this down. Let me know what I can do please. Thanks --FC
Re: espeakup sid arm64 under qemu
Hello, Frank Carmickle, le ven. 03 mars 2023 10:42:17 -0500, a ecrit: > If anyone knows anything to help with this situation, I'd really appreciate > it. Also, where might be a better place to discuss this? I don't see a debian > audio related mailing list. Maybe a qemu related mailing list is the right > place? Yes, I believe it'd rather be discussed on a qemu list: https://wiki.qemu.org/Contribute/MailingLists I'd say you can send a common mail to qemu-arm and qemu-devel, and also the maintainers of the overall audio stack, Gerd Hoffmann and Philippe Mathieu-Daudé Samuel
espeakup sid arm64 under qemu
Greetings all, After taking weeks to just get a machine installed, I'm finally finding that the virtualized audio device from qemu and the linux driver aren't getting along so well. At some point the virtualized system stops being able to play sound, and the host systems audio buffer adjusts simultaneously up to being large enough to hold a half second of audio, causing the system to because difficult to use. As soon as I stop the qemu process it returns the audio buffer to a reasonable size. Sometimes the linux kernel prints snd_hda_intel :00:02.0: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj. in kmsg. I have increased this value all the way up to 512, which brings noticeably laggy performance, and it still prints IRQ timing workaround in kmsg. If anyone knows anything to help with this situation, I'd really appreciate it. Also, where might be a better place to discuss this? I don't see a debian audio related mailing list. Maybe a qemu related mailing list is the right place? --FC
Re: espeakup stops speaking version 1:0.90-11
Hi again, > On Oct 28, 2022, at 11:16 AM, Samuel Thibault wrote: > > Frank Carmickle, le ven. 28 oct. 2022 11:03:58 -0400, a ecrit: >> I have been taking newer kernels. > > Kernel device drivers introduce buffering, so it can be useful to > investigate if it's a new kernel that introduced the regression. I couldn't get my hands on a binary for 5.17.x. I booted the current bullseye kernel, 5.10.149-2. I still had the problem, although in a different way. This time the speech stopped before the buffer overwriting. As soon as I restarted speech the buffer overwriting was happening. I'm guessing they are still very much related but once it happens you can get an immediate stopping of speech or you can get the buffer overwriting first. I'll keep poking away at this. If you have any other ideas, toss them my way. I'll try them all. I'm booted on to 6.0.2 again. --FC
Re: espeakup stops speaking version 1:0.90-11
Frank Carmickle, le ven. 28 oct. 2022 11:03:58 -0400, a ecrit: > I have been taking newer kernels. Kernel device drivers introduce buffering, so it can be useful to investigate if it's a new kernel that introduced the regression. Samuel
Re: espeakup stops speaking version 1:0.90-11
Hi Samuel, et al I've been trying for quite some time to figure this one out. I think that espeakup's stopping speaking happens after something changes the audio buffering somehow. After a time the audio buffering is no longer interrupting, or flushing but the next bit of speech is talking over the audio buffer, even though it is quite short. I thought I had a reproducible situation where as soon as the load got how enough this buffering change would happen. When I reverted libpulse0 to 14.2 it took a lot longer to get in to that state but it eventually got there anyway. Any idea of who might be changing the audio buffering such that espeakup talks over itself when doing screen review? Maybe knowing this info can help us find the source of the trouble. I've reverted to older espeak and espeakup without seeing benefit. libasound has not updated in the time since it started acting this way. I have been taking newer kernels. I haven't tried booting a 5.17 kernel to see if that has any impact as of yet. Thanks for any help. It's very much appreciated. --FC > On Oct 7, 2022, at 5:21 PM, Samuel Thibault wrote: > > Hello, > > It would be useful to determine which version of espeakup brought this > regression? Possibly also try to change the version of libespeak-ng1. > > Samuel > > Frank Carmickle, le jeu. 06 oct. 2022 15:55:01 -0400, a ecrit: >> Hello all, >> >> Anyone else seeing this? I haven't got any logging to show as of yet, and >> I'm not sure how to get it as of yet. If anyone could tell me what to adjust >> to get some logging, as I'm not seeing any now, I'd appreciate it. >> >> For now a killall -9 espeakup gets systemd to respawn it. This is happening >> quite a bit, every tenish minutes or so. Also, it seems to stop speaking >> when I do screen review by word. >> >> Speakup is kernel 5.19.0-2-amd64. >> >> >> Thanks, >> --FC
Re: espeakup stops speaking version 1:0.90-11
Hello, It would be useful to determine which version of espeakup brought this regression? Possibly also try to change the version of libespeak-ng1. Samuel Frank Carmickle, le jeu. 06 oct. 2022 15:55:01 -0400, a ecrit: > Hello all, > > Anyone else seeing this? I haven't got any logging to show as of yet, and I'm > not sure how to get it as of yet. If anyone could tell me what to adjust to > get some logging, as I'm not seeing any now, I'd appreciate it. > > For now a killall -9 espeakup gets systemd to respawn it. This is happening > quite a bit, every tenish minutes or so. Also, it seems to stop speaking when > I do screen review by word. > > Speakup is kernel 5.19.0-2-amd64. > > > Thanks, > --FC
re: killall espeakup
speechctl doesn't exist, so sysctl stop espeakup ought to get the job done. Jude "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) .
Re: espeakup stops speaking version 1:0.90-11
Try sysctl stop speechctl That probably works better. killall is pre-systemd and likely not compatible. Jude "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) . On Thu, 6 Oct 2022, Frank Carmickle wrote: > Hello all, > > Anyone else seeing this? I haven't got any logging to show as of yet, and I'm > not sure how to get it as of yet. If anyone could tell me what to adjust to > get some logging, as I'm not seeing any now, I'd appreciate it. > > For now a killall -9 espeakup gets systemd to respawn it. This is happening > quite a bit, every tenish minutes or so. Also, it seems to stop speaking when > I do screen review by word. > > Speakup is kernel 5.19.0-2-amd64. > > > Thanks, > --FC > >
espeakup stops speaking version 1:0.90-11
Hello all, Anyone else seeing this? I haven't got any logging to show as of yet, and I'm not sure how to get it as of yet. If anyone could tell me what to adjust to get some logging, as I'm not seeing any now, I'd appreciate it. For now a killall -9 espeakup gets systemd to respawn it. This is happening quite a bit, every tenish minutes or so. Also, it seems to stop speaking when I do screen review by word. Speakup is kernel 5.19.0-2-amd64. Thanks, --FC
Re: changing the scheduling and niceness of espeakup and related processes
Nick Gawronski, le lun. 28 févr. 2022 22:43:04 -0600, a ecrit: > Yes that fix allowed me to cat the entire perl INSTALL file and hear it > from beginning to end. Good! > Is this fix possible to add to the normal upstream version? Sure, I was just waiting for your confirmation of the fix. It's now submitted on: https://github.com/linux-speakup/espeakup/pull/48 Samuel
Re: changing the scheduling and niceness of espeakup and related processes
Hi, Yes that fix allowed me to cat the entire perl INSTALL file and hear it from beginning to end. Is this fix possible to add to the normal upstream version? Nick Gawronski On 2/28/2022 6:42 PM, Samuel Thibault wrote: Hello, Nick Gawronski, le lun. 28 févr. 2022 14:26:13 -0600, a ecrit: Hi, Yes it always stops at that section talking about dynamic loading Ok, so that's a problem with espeak-ng refusing too much text at the same time. I had a look and implemented something. Could you try to install https://people.debian.org/~sthibault/tmp/bullseye-tmp/espeakup_0.80-20+deb11u1+throttle_amd64.deb to check that it fixes the issue for you? It should be noted that when cat-ing very long files you won't be able to interrupt speech immediately, for perl's INSTALL file it seems to be taking a few seconds for the whole text to be buffered before one can interrupt the speech. That's something that'd probably need to be fixed in the kernel itself. Samuel
Re: changing the scheduling and niceness of espeakup and related processes
Hello, Nick Gawronski, le lun. 28 févr. 2022 14:26:13 -0600, a ecrit: > Hi, Yes it always stops at that section talking about dynamic loading Ok, so that's a problem with espeak-ng refusing too much text at the same time. I had a look and implemented something. Could you try to install https://people.debian.org/~sthibault/tmp/bullseye-tmp/espeakup_0.80-20+deb11u1+throttle_amd64.deb to check that it fixes the issue for you? It should be noted that when cat-ing very long files you won't be able to interrupt speech immediately, for perl's INSTALL file it seems to be taking a few seconds for the whole text to be buffered before one can interrupt the speech. That's something that'd probably need to be fixed in the kernel itself. Samuel
Re: changing the scheduling and niceness of espeakup and related processes
Hi, Yes it always stops at that section talking about dynamic loading but if I use less or more I am able to read past that portion of the file. I just tried it again and yes I keep getting the same results. Nick Gawronski On 2/28/2022 12:36 PM, Samuel Thibault wrote: Hello, Nick Gawronski wrote: Is there a way to cat a file or run a program before catting the file so that the line numbers can be written? man cat says -n The file stops speaking after the text perl itself under the section dynamic loading. Is it always stopping there? Samuel
Re: changing the scheduling and niceness of espeakup and related processes
Hello, Nick Gawronski wrote: > Is there a way to cat a file or run a program before catting the file > so that the line numbers can be written? man cat says -n > The file stops speaking after the text perl itself under the > section dynamic loading. Is it always stopping there? Samuel
Re: changing the scheduling and niceness of espeakup and related processes
Hi, Yes I am using the latest Bullseye version from your repository. Is there a way to cat a file or run a program before catting the file so that the line numbers can be written? The file stops speaking after the text perl itself under the section dynamic loading. When I ran nano -w INSTALL and pressed control C after searching for the dynamic loading I got line number 522 and it said it was at %19. Is this anymore helpful? Nick Gawronski On 2/27/2022 4:52 PM, Samuel Thibault wrote: Hello, Nick Gawronski wrote: In the Bullseye packages of espeakup and espeak-ng with the english voice Which version do you have *exactly*? Your mail quoted my repo https://people.debian.org/~sthibault/tmp/bullseye did you install that? if you download the perl sources package and cat the INSTALL file the file stops speaking some of the way down. I am not sure how far from the end of the file it stops speaking "some" is not precise enough for me to do anything about this report. Is that after a hundred lines, a thousand lines, ten thousand lines, a million lines? I tried to cat a file, I stopped listening after 500 lines were properly read, I don't even know whether that means I wasn't able to reproduce the issue, or whether that means I wasn't patient enough... Samuel
Re: changing the scheduling and niceness of espeakup and related processes
Hello, Nick Gawronski wrote: > In the Bullseye packages of espeakup and espeak-ng with the english > voice Which version do you have *exactly*? Your mail quoted my repo https://people.debian.org/~sthibault/tmp/bullseye did you install that? > if you download the perl sources package and cat the INSTALL file the > file stops speaking some of the way down. I am not sure how far from the > end of the file it stops speaking "some" is not precise enough for me to do anything about this report. Is that after a hundred lines, a thousand lines, ten thousand lines, a million lines? I tried to cat a file, I stopped listening after 500 lines were properly read, I don't even know whether that means I wasn't able to reproduce the issue, or whether that means I wasn't patient enough... Samuel
Re: changing the scheduling and niceness of espeakup and related processes
Hi, In the Bullseye packages of espeakup and espeak-ng with the english voice if you download the perl sources package and cat the INSTALL file the file stops speaking some of the way down. I am not sure how far from the end of the file it stops speaking but if I review the screen with the speakup review keys I see the end of the file and it looks like it is way past the portion where speech stops. When I did the reviewing I did not find that there was much delay like there was before when speech had stopped in the past but wanted to report this so it could get looked into as soon as possible as I myself when reading a long file like to use cat to read the entire thing without having less or more telling me to go from page to page. Is there anything else I can provide to help get this issue fixed as my expected outcome is that the file will read from the beginning to the end with no stopping part of the way down the file and having to go to using more or less because the catting option does not work? Nick Gawronski On 2/13/2022 4:59 PM, Samuel Thibault wrote: Samuel Thibault, le dim. 13 févr. 2022 23:54:59 +0100, a ecrit: Nick Gawronski, le dim. 13 févr. 2022 16:48:03 -0600, a ecrit: Is there a way that these fixes can be put into the next point release of stable I can propose the fix for stable, yes. I will just wait for it to migrate to testing for some time, to watch for any unwanted side effect. In the meanwhile, I have uploaded a bullseye build on https://people.debian.org/~sthibault/tmp/bullseye Samuel
Re: changing the scheduling and niceness of espeakup and related processes
Samuel Thibault, le dim. 13 févr. 2022 23:54:59 +0100, a ecrit: > Nick Gawronski, le dim. 13 févr. 2022 16:48:03 -0600, a ecrit: > > Is there a way that these fixes can be put into the next point > > release of stable > > I can propose the fix for stable, yes. I will just wait for it to > migrate to testing for some time, to watch for any unwanted side effect. In the meanwhile, I have uploaded a bullseye build on https://people.debian.org/~sthibault/tmp/bullseye Samuel
Re: changing the scheduling and niceness of espeakup and related processes
Hello, Nick Gawronski, le dim. 13 févr. 2022 16:48:03 -0600, a ecrit: > Is there a way that these fixes can be put into the next point > release of stable I can propose the fix for stable, yes. I will just wait for it to migrate to testing for some time, to watch for any unwanted side effect. Samuel
