[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: espeakup stops speaking bookworm arm64



Thank you for bringing this up again, Geoff.

Please confirm that using the same virtualization layer espeakup from buster, kernel 4.19.x is in fact still working reliably.

Please also confirm that you are finding this bug on AMD64 virtual machines?

Thank you,
--FC


> On Aug 17, 2025, at 15:37, Geoff Shang <geoff@QuiteLikely.com> wrote:
> 
> Hi,
> 
> So I looked at espeakup in Trixie and none of the changes listed seem to address this issue.  So I'm guessing this is still present in Trixie, though I've yet to test it.
> 
> Honestly, this bug drives me crazy.  As mentioned in previous posts, part of my work duties is to troubleshoot customer issues on call.  These issues are, by definition, urgent, and espeakup is particularly prone to crashing under these circumstances.  It seems most likely to happen when reviewing by character.
> 
> So I would very much like to get this one fixed!
> 
> So I went hunting for bug reports.
> 
> I found two bug reports, both of which may or may not be the same issue.
> 
> The Debian bug is bug #1024549[1].  This was reported in the context of the installer rather than the installed system, but it's interesting that this is also a VM.  It was also reported in November 2022!
> 
> I don't understand the technical issues enough to know if this is, in fact, the same bug, but the error message does look familiar.
> 
> I note that Arnaud reported that espeakup crashed, which it doesn't appear to do for me as I actually have to kill it for it to recover.  So maybe it's not the same issue.
> 
> The other issue I found is issue #45[2] on the espeakup issue tracker on GitHub.
> 
> This one *does* appear to be the same issue, so far as I can tell.  It was reported in February 2022 and looks like nothing has been done on it.
> 
> In fact, it would appear that the most extensive investigation on this issue has taken place in this email thread.
> 
> Please, let us mere mortals who rely on this stuff working know what we can do to help get this resolved.
> 
> Cheers,
> Geoff.
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024549
> [2] https://github.com/linux-speakup/espeakup/issues/45
> 
> 
> 
> 
> 
> 
> On Fri, 3 Jan 2025, Geoff Shang wrote:
> 
>> 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 at work which are time sensitive.
>> 
>> I have actually not upgraded one of my machines from Bullseye due to this issue.
>> 
>> At the very least, I would not like to see this bug make it into Trixie.
>> 
>> Geoff.
>> 
>> 
>> On Fri, 15 Mar 2024, Frank Carmickle wrote:
>> 
>>> 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 <geoff@QuiteLikely.com> 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.
>> 
>> 
> 


Reply to: