pulseaudio and espeakup

[Samuel Thibault]

Hello,

I had a closer look at all of this.

Felipe Sateler, le ven. 02 févr. 2018 20:38:43 -0300, a ecrit:
> There are two mechanisms by which pulseaudio coordinates device access.
> 
> The first one is the `uaccess` mechanism provided by udev. Pulseaudio
> monitors the device for ACL changes, and releases it when the device
> is no longer accessible to the user. This is how pulseaudio drops
> access to the device when switching VT.
> 
> The second one is a dbus negotiation protocol. It is described
> here[1]. Currently it is respected by at least pulseaudio, jack2 and
> kodi. The pulseaudio support is implemented in src/modules/reserve*.
> 
> [1] http://git.0pointer.net/reserve.git/tree/reserve.txt

Ok, thanks for the details.

AIUI, the dbus negotiation protocol can only be used inside a given
user's session, which makes sense anyway since it's cooperative.

Concerning uaccess, AIUI it wouldn't do anything if e.g. the user is
both logged in the Linux console and the Xorg console.

Now, given that:

- in Xorg, speech needs to be emitted by speech-dispatcher through
pulseaudio, so it can e.g. mix with firefox' pulseaudio use,

- on the console, espeakup needs to be run even before users log in,
either as root or another user which can somehow access the audio card.
It needs to keep that access whatever happens on the console,

I'm afraid the only solution we have is that both espeakup and
speech-dispatcher just release the audio device when they think they
won't have anything to speak in the close future.

- That way, when switching from the Linux console to Xorg, pulseaudio
can reacquire the audio card for speech-dispatcher, and conversely from
Xorg to the Linux console, pulseaudio will release the audio card so
that espeakup can take it. Of course if an application in Xorg is still
using the audio card, pulseaudio will keep running the card and espeakup
won't be able to take it. I don't think we have any solution against
that.

- determining when to release the audio device is tricky. We don't want
to just do it as soon as speech is over, as it'd permanently bring ugly
clicks and such. We could do it after some idle time. Ideally we'd know
when switching between Xorg and the Linux console. espeakup could be
notified by speakup to shut up immediately when the console switches to
graphical mode. I however don't think Orca has a way to know and tell
speech-dispatcher that the Xorg server has lost focus, so we'd have to
introduce the idle feature in speech-dispatcher.  The delay can be made
configurable of course.  A short delay means more potential for clicks,
but also a shorter speak switch time when going back to the console.


How do users think about it?

Samuel