Re: making espeakup and orca run on the mate desktop so I can switch between the console and the desktop

["K0LNY ??" <glenn@ervin.email>]

I'm wondering for my friend with this problem,
Can he set espeakup to use an old external synth, and if so, will it fix 
this issue?
Glenn
----- Original Message ----- 
From: "Sebastian Humenda" <shumenda@gmx.de>
To: <debian-accessibility@lists.debian.org>
Sent: Monday, March 3, 2025 11:18 AM
Subject: Re: making espeakup and orca run on the mate desktop so I can 
switch between the console and the desktop


Hi

nick@nickgawronski.com schrieb am 03.03.2025, 10:40 -0600:
>Hi, With the current configuration I can use both orca and espeakup but 
>only
>one at a time.  I have my system setup to boot into the text console then
>start mate.  At that point orca takes over and I am able to use the desktop
>with no issues.  When I try to change back to the first console I find that 
>I
>get no speech from espeakup which from looking at the status of the service
>is still running.

It is likely due to the fact the the graphical session starts pulse, or if 
on
Trixie, pipewire. These sound servers are run per user and grab the sound
output exclusively. The  trouble is that command-line screen readers like
BRLTTY or speakup/espeakup run as root and would require a way to also 
access
the sound card. There's a discussion on the Debian Wiki on the accessibility
page.

I have two set ups and none is ideal; the description is technical and I can
elaborate on request:

1.  Run pulse as an explicit user daemon of my user and adapt the BRLTTY
    systemd unit to depend on this unit. This works but delays the screen
    reader to a late point in the boot.
    This also requires disabling the autospawn feature of pulse + the
    autostart by the desktop environment. The process is involved.

    Has anyone run a comparable setup with pipewire?

2.  Run pulse or pipewire as root. As this is not supported by upstream, it 
is
    quickly becoming a mess. Especially when bluetooth/USB headsets are
    involved.

3.  Let the console screen reader use the speech dispatcher instance of the
    user that runs the sound server. Also very cryptic to set up and enables
    speech only late in the boot process. I've ben using it on Trixie 
systems
    where pipewire is the default.


@Samuel, have you any idea how to solve this rather complex issue? I've been
working around it for years but didn't see a nice solution yet.

Cheers
Sebastian