Re: pulseaudio and espeakup

[Jude DaShiell]

I wonder, do udev and dbus ever fight?  If so, what if any action does 
pulseaudio take during any such fight?  Perhaps a priority assignment is 
done and in some instances the priority assignment turns out wrong for 
accessibility.


On Sat, 3 Feb 2018, Samuel Thibault wrote:


Date: Fri, 2 Feb 2018 18:30:23
From: Samuel Thibault 
To: Jude DaShiell 
Cc: debian-accessibility@lists.debian.org,
pkg-pulseaudio-de...@lists.alioth.debian.org,
Scott Leggett 
Subject: Re: pulseaudio and espeakup
Resent-Date: Fri,  2 Feb 2018 23:30:41 + (UTC)
Resent-From: debian-accessibility@lists.debian.org

Jude DaShiell, on ven. 02 f?vr. 2018 15:08:33 -0500, wrote:

Perhaps lost or dropped might provide some interesting reading.


Thanks for the suggestion! Unfortunately nothing interesting showed up.

Samuel




--

Re: pulseaudio and espeakup

[Samuel Thibault]

Felipe Sateler, on ven. 02 févr. 2018 20:38:43 -0300, wrote:
> There are two mechanisms by which pulseaudio coordinates device access.

Thanks!

Samuel

Re: pulseaudio and espeakup

[Felipe Sateler]

On Fri, Feb 2, 2018 at 4:27 PM, Samuel Thibault  wrote:
> Hello,
>
> Samuel Thibault, on sam. 06 janv. 2018 14:45:04 +0100, wrote:
>> Scott Leggett, on sam. 06 janv. 2018 23:47:42 +1100, wrote:
>> > can deal with devices being assigned to them and going away.
>>
>> It seems promising but I need more details. At which layer does this
>> happen? Does pulseaudio have hooks for this? I.e. espeakup would provide
>> hooks for relieving the audio device when pulseaudio feels the need to?
>> It seems to me that it's the kind of approach which would work.
>
> I haven't had any feedback on this.  What is meant by "assigned to them
> and going away"?  Which pulseaudio functions implements this?  I have
> looked for "going", "away", "destroy", etc. in the pulseaudio headers (I
> didn't find any other documentation in the source package), to no avail.
>
> Do you have ideas on which keywords I should look for in pulseaudio?
> (I'm fine with diving in the source coed, I'd just rather not start
> without any clue what to look for)
>

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

-- 

Saludos,
Felipe Sateler

Re: pulseaudio and espeakup

[Samuel Thibault]

Jude DaShiell, on ven. 02 févr. 2018 15:08:33 -0500, wrote:
> Perhaps lost or dropped might provide some interesting reading.

Thanks for the suggestion! Unfortunately nothing interesting showed up.

Samuel

Re: pulseaudio and espeakup

[Jude DaShiell]

Perhaps lost or dropped might provide some interesting reading.

On Fri, 2 Feb 2018, Samuel Thibault wrote:


Date: Fri, 2 Feb 2018 14:27:23
From: Samuel Thibault 
To: debian-accessibility@lists.debian.org,
pkg-pulseaudio-de...@lists.alioth.debian.org,
Scott Leggett 
Subject: Re: pulseaudio and espeakup
Resent-Date: Fri,  2 Feb 2018 19:28:07 + (UTC)
Resent-From: debian-accessibility@lists.debian.org

Hello,

Samuel Thibault, on sam. 06 janv. 2018 14:45:04 +0100, wrote:

Scott Leggett, on sam. 06 janv. 2018 23:47:42 +1100, wrote:

can deal with devices being assigned to them and going away.


It seems promising but I need more details. At which layer does this
happen? Does pulseaudio have hooks for this? I.e. espeakup would provide
hooks for relieving the audio device when pulseaudio feels the need to?
It seems to me that it's the kind of approach which would work.


I haven't had any feedback on this.  What is meant by "assigned to them
and going away"?  Which pulseaudio functions implements this?  I have
looked for "going", "away", "destroy", etc. in the pulseaudio headers (I
didn't find any other documentation in the source package), to no avail.

Do you have ideas on which keywords I should look for in pulseaudio?
(I'm fine with diving in the source coed, I'd just rather not start
without any clue what to look for)

Samuel




--

Re: pulseaudio and espeakup

[Samuel Thibault]

Hello,

Samuel Thibault, on sam. 06 janv. 2018 14:45:04 +0100, wrote:
> Scott Leggett, on sam. 06 janv. 2018 23:47:42 +1100, wrote:
> > can deal with devices being assigned to them and going away. 
> 
> It seems promising but I need more details. At which layer does this
> happen? Does pulseaudio have hooks for this? I.e. espeakup would provide
> hooks for relieving the audio device when pulseaudio feels the need to?
> It seems to me that it's the kind of approach which would work.

I haven't had any feedback on this.  What is meant by "assigned to them
and going away"?  Which pulseaudio functions implements this?  I have
looked for "going", "away", "destroy", etc. in the pulseaudio headers (I
didn't find any other documentation in the source package), to no avail.

Do you have ideas on which keywords I should look for in pulseaudio?
(I'm fine with diving in the source coed, I'd just rather not start
without any clue what to look for)

Samuel

Re: Evince, again not accessible?

[Alex ARNAUD]

Le 02/02/2018 à 10:00, MENGUAL Jean-Philippe a écrit :

Hi,

Few time ago, a new evince release was uploaded in testing. So far text 
PDF were accessible again (after a tim they were not readable at all). 
With this new release, they are again not accessible. Should I fill a 
bug? Reproducing is simple: open Evince, press f7, accept to enable the 
browse mode, press down arrow, and nothing is read even in a text PDF file.


Hello JP,

I can't confirm this on Debian Sid, Orca master and Evince 3.26.0-3.

Best regards.
--
Alex ARNAUD
Visual-Impairment Project Manager
Hypra - "Humanizing technology"

Evince, again not accessible?

[MENGUAL Jean-Philippe]

Hi,

Few time ago, a new evince release was uploaded in testing. So far text
PDF were accessible again (after a tim they were not readable at all).
With this new release, they are again not accessible. Should I fill a
bug? Reproducing is simple: open Evince, press f7, accept to enable the
browse mode, press down arrow, and nothing is read even in a text PDF file.

Thanks

Regards

-- 
signature_jp_2
Logo Hypra  JEAN-PHILIPPE MENGUAL
DIRECTEUR TECHNIQUE ET QUALITÉ
102, rue des poissonniers, 75018, Paris
Tel : +331 84 73 06 61  Mob : +336 76 34 93 37

jpmeng...@hypra.fr 
www.hypra.fr 
Facebook Hypra  Twitter Hypra
 Linkedin Jean-Philippe