Re: [orca-list] Solving screenreader sound problems in presence of sound servers once and for all



This is the thing, you need hacks to work around stuff, and then you get
drawbacks.
For example does your setup allow me to play sound on gui and hear it on
console when I log in to the same user, or, play sound on console when
screenreader is speaking?
Like the last one is likely possible if espeakup uses dmix.

W dniu 20.02.2021 o 14:08, Jookia pisze:
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






Attachment: OpenPGP_signature
Description: OpenPGP digital signature



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