Re: Solving screenreader sound problems in presence of sound servers once and for all

[Jookia <contact@jookia.org>]

For the past year or so a friend and I have had PulseAudio and espeakup
working together fine on Linux. All you have to do is get Pulse to let
go of control of the sound card when you switch TTYs, or something like
that. It's a combination of udev rule and systemd user service.
With some more tricks you can even get it to speak the bootup sequence
and some logout stuff.

On Sat, Feb 20, 2021 at 01:38:21PM +0100, Michał Zegan wrote:
> Hi,
> Sending that mail to orca and speakup lists, because I am asking for
> ideas from the blind community especially console screenreader developers.
> There is now a new sound server called pipewire that seems to merge good
> sides of both pulseaudio and jack, I am just testing it and working with
> it daily, and except some sound stuttering and other bugs it's really
> usable and stable. It is currently in active development, but ready for
> wider testing.
> I think this is a good opportunity to fix, or take part in fixing, our
> problem: how to get sound in console, including pre login and post
> login, without having to either uninstall any and all sound systems and
> lose their capabilities, or hack around/work around the issue?
> I think we have to step in at least when it comes to ideas, because I
> don't think they know how to do it properly, and honestly, me neither.
> Pipewire will support, and I think already does support, running as a
> system wide process, and that would technically solve the problem,
> except it has it's drawbacks. Note pipewire, like pa and jack, is
> normally running as an user service, and I think for good reasons, at
> least in case of graphical sessions.
> It would be definitely visible to those using user accounts because
> users won't have their own sound settings etc. Possibly other use cases
> may also not be possible or become hacky, like multiseat or remote
> desktop with sound. There are also security related drawbacks to system
> wide pipewire, and some of us may care, like one user being able to
> influence other user's sound.
> Does anyone have any ideas about how the problem could be solved without
> sacrificing things like pipewire's low latency goals? I do have some but
> not sure how well would they work, like some way to handover devices
> between system wide and user wide instances, and either a way to switch
> between pipewires on the fly from a system service like espeakup/fenrir,
> or in case of things like fenrir, being able to run multiple instances
> of fenrir and being able to handover when switching sessions/vt's.
> Or some way to still use system wide server in case of console sessions,
> but not sure how that would be implemented considering how device
> handover normally works.
> Note pipewire is now started by systemd user, so it's not per session,
> it's per user. So you cannot just not start it on console login because
> you may be using both a gui and a console, for example. and possibly
> three ssh sessions, this probably starts pipewire too even though ssh
> sessions are non local and would not cause sound device handover themselves.
> 
> Waiting for some insight on that. We may contact developers on gitlab or
> irc, but today is saturday and the main pw dev is unavailable.
> Best regards,
> Michał Zegan
>