On Mon, 6 Jan 2025, Frank Carmickle wrote:
Thank you for waking up this thread, again.
Am I understanding you correctly, that you are not having this issue in
bullseye?
Correct, I am not.
Cheers,
Geoff.
Thank you for waking up this thread, again.
Am I understanding you correctly, that you are not having this issue in
bullseye?
Thank you,
--FC
> On Jan 3, 2025, at 13:52, Geoff Shang wrote:
>
> Hi,
>
> Was a bug ever filed on this issue?
>
> If not, I can open one, but I don't really underst
Hi Geoff,
Can you install espeak-ng on Buster?
Perhaps it will be more reliable than espeak.
Glenn
- Original Message -
From: "Geoff Shang"
To: "Debian Accessibility Team"
Sent: Friday, January 3, 2025 12:52 PM
Subject: Re: espeakup stops speaking bookworm arm64
On Fri, 3 Jan 2025, K0LNY ?? wrote:
Can you install espeak-ng on Buster?
Perhaps it will be more reliable than espeak.
I'm already using espeak-ng.
However, as I recall, the issue was determined to be with espeakup, not
espeak-ng.
Certainly, killing espeakup and having it respawn clears th
Hi,
Was a bug ever filed on this issue?
If not, I can open one, but I don't really understand the technical stuff
as much as I would like to.
But I would like to see it fixed. This happens to me on a regular basis
and is very annoying, especially during high priority issue
investigations a
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
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.
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
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.
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 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 h
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 :)
> > > >
>
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 thr
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
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 defin
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:2
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
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
>
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 0x
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 trie
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
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 instea
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
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?
th
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.
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 ?
>
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 c
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
> >
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 ed
> 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 speak
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 r
l 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
nt: 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, Jam
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, 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 t
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 Pl
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 backtrac
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 ar
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 ORC
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
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 method
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 win
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
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 bac
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 gener
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 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
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 s
> "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 minima
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> w
> "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
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
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
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 the
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
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
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 na
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
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
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
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
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
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 e
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
64 matches
Mail list logo
