Re: Pluseaudio, speech-dispatcher, and console + graphical screen readers

[Christian Schoepplein]

Hi Luke,

On Tue, Oct 06, 2015 at 08:49:07AM +1100, Luke Yelavich wrote:
>Currently work is ongoing to refactor the audio code in Speech
>Dispatcher. However, this probably could be done even now, and is likely
>the way to go given that the new code in Speech DIspatcher has no ETA on
>release, as there are other improvements also being made.

Can you tell a bit more about the things that will be changed in 
speech-dispatcher please?

And please have inmind, that there are users who are working in parallel 
in the console and in desktop environments, and have to use speech 
output in both worlds...

Thanks and all the best from Munich,

  Christian


-- 
Christian Schoepplein -  - http://schoeppi.net

Re: Pluseaudio, speech-dispatcher, and console + graphical screen readers

[Halim Sahin]

Hi,
On Di, Okt 06, 2015 at 08:49:07 +1100, Luke Yelavich wrote:
> Currently work is ongoing to refactor the audio code in Speech
> Dispatcher. However, this probably could be done even now, and is likely
> the way to go given that the new code in Speech DIspatcher has no ETA on
> release, as there are other improvements also being made.

Could you please explain how the refactoring will help solving the
described issues?
Will speech-dispatcher work for console screenreaders and orca running
on the same machine?
What's is not working in speechd and must be refactored to work with
pulseaudio?
Regards
Halim

Re: Pluseaudio, speech-dispatcher, and console + graphical screen readers

[Luke Yelavich]

On Wed, Sep 30, 2015 at 05:36:44AM AEST, Sam Hartman wrote:
> So, for myself, I'd really like to  be able to use pulseaudio.  Without
> pulseaudio it's very hard to use bluetooth  audio.
> To make that work well, what would need to happen is that we'd need to
> get speech dispatcher to not hold its audio stream in a running state
> when it's not talking.

Currently work is ongoing to refactor the audio code in Speech
Dispatcher. However, this probably could be done even now, and is likely
the way to go given that the new code in Speech DIspatcher has no ETA on
release, as there are other improvements also being made.

I'll see what can be done.

Luke

Re: Pluseaudio, speech-dispatcher, and console + graphical screen readers

[Tobias Platen]

On 04.10.2015 09:33, Halim Sahin wrote:

Hi,
On Fr, Okt 02, 2015 at 03:41:59 +, Sam Hartman wrote:

the latency you're talking about there is very close to what you'd see
if you restart the streat between speech-dispatcher and pulseaudio and
that restarts the alsa stream within pulseaudio.


My prefered setup doesn't restart alsa streams in pa.
Pa is installed and can be used in the graphical desktop etc.
Speech-dispatcher uses alsa.




Actually, I do have hard data on this.  I use espeak with emacspeak
through pulseaudio directly without speech-dispatcher.


Which is a different approach and not much comparable :-(.
Are you using orca as well?


I also had problem with pulseaudio when I installed speech-dispatcher 
and SBL for testing purposes on my Olinuxino while working at the 
Blindenzentrum of the University of Applied Sciences. Many other audio 
applications do have similar problems, such as praat which I do use 
while working on speech synthesis software. In praat I don't hear any 
sound when pulseaudio is active.

Re: Pluseaudio, speech-dispatcher, and console + graphical screen readers

[Christian Schoepplein]

Hi Tobias,

On Sun, Oct 04, 2015 at 11:35:42AM +0200, Tobias Platen wrote:
>I also had problem with pulseaudio when I installed speech-dispatcher and SBL
>for testing purposes on my Olinuxino while working at the Blindenzentrum of
>the University of Applied Sciences. Many other audio applications do have
>similar problems, such as praat which I do use while working on speech
>synthesis software. In praat I don't hear any sound when pulseaudio is
>active.

have you tried the setup I described a few days ago? I use pulseaudio 
and speech-dispatcher in system mode which is not the prefered way to run 
both services, but it is working fine and I do not have any latencies in 
speech output anywhere...

@Halim: Would you describe more detailed your setup with alsa please? 
Wich steps did you perform after a fresh installation of Debian?

Cheers,

  Schoepp


-- 
Christian Schoepplein -  - http://schoeppi.net

Re: Pluseaudio, speech-dispatcher, and console + graphical screen readers

[Halim Sahin]

Hi,
On Fr, Okt 02, 2015 at 03:41:59 +, Sam Hartman wrote:
> the latency you're talking about there is very close to what you'd see
> if you restart the streat between speech-dispatcher and pulseaudio and
> that restarts the alsa stream within pulseaudio.

My prefered setup doesn't restart alsa streams in pa.
Pa is installed and can be used in the graphical desktop etc.
Speech-dispatcher uses alsa.


> 
> Actually, I do have hard data on this.  I use espeak with emacspeak
> through pulseaudio directly without speech-dispatcher.  

Which is a different approach and not much comparable :-(.
Are you using orca as well?

Re: Pluseaudio, speech-dispatcher, and console + graphical screen readers

[Sam Hartman]

> "Halim" == Halim Sahin  writes:

Halim> Hi, I am not sure if I got it right.  If you want to shutdown
Halim> connection to pa every time after speechoutput this will
Halim> produce latency and would reduce responsiveness of speechd.
Halim> Responsiveness is an important thing for a11y Applications.

I think that if you haven't been speaking for say 10 seconds or so, the
sort of latency you're talking about even if you have to pull the ALSA
stream back up within pulseaudio itself is entirely acceptable.
Certainly I don't see latency problems on ]Android when I touch the
device after it's suspended audio.  It's not using pulse, but I suspect
the latency you're talking about there is very close to what you'd see
if you restart the streat between speech-dispatcher and pulseaudio and
that restarts the alsa stream within pulseaudio.

Actually, I do have hard data on this.  I use espeak with emacspeak
through pulseaudio directly without speech-dispatcher.  If I don't have
speech-dispatcher running, which is to say, nothing is holding the alsa
stream open at the pulseaudio level, responsiveness is fine.  So, no, I
don't think the issue you're describing is a significant problem if you
hold the stream open for a few seconds after you're done.

Re: Pluseaudio, speech-dispatcher, and console + graphical screen readers

[Halim Sahin]

Hi,
I am not sure if I got it right.
If you want to shutdown connection to pa every time after speechoutput
this will produce latency and would reduce responsiveness of speechd.
Responsiveness is an important thing for a11y Applications.

Maybe there is an easy fix for accessible installations of debian:

https://wiki.archlinux.org/index.php/PulseAudio#ALSA.2Fdmix_without_grabbing_hardware_device
These steps could be configured if someone installs debian with brltty
or with speech.
Please try it out!
Regards
Halim

Re: Pluseaudio, speech-dispatcher, and console + graphical screen readers

[Sam Hartman]

So, for myself, I'd really like to  be able to use pulseaudio.  Without
pulseaudio it's very hard to use bluetooth  audio.
To make that work well, what would need to happen is that we'd need to
get speech dispatcher to not hold its audio stream in a running state
when it's not talking.
If we do that, pulseaudio will suspend its alsa connection reasonably
quickly.
You cannot use pulseaudio and say speakup exactly at the same time, but
the experience is generally good enough.

Re: Pluseaudio, speech-dispatcher, and console + graphical screen readers

[Christian Schoepplein]

Hi,

sorry, late answer, but this weekend I've installed a new laptop and 
I again needed to configure all the things necesary to have speech 
support in console and graphical environment, so now I can write all 
things together...

On Mon, Aug 31, 2015 at 05:11:27PM +0200, Mario Lang wrote:
>Christian Schoepplein  writes:
>> On Fri, Aug 28, 2015 at 12:33:41AM +0200, Samuel Thibault wrote:
>>>As discussed during DebConf15, we target enabling the accessibility
>>>stack by default.  I've studied that a bit more, here are my thoughts:
>>
>> Diskussing accessibility of Debian should not only be reduced to the 
>> issues you mensioned, Samuel, there are a few more things that need to 
>> be worked out, I think.
>
>> For example the fact, that the way pulseaudio, speech-dispatcher and all 
>> this stuff needs to be configured to work propperly, when orca and a 
>> console screen reader is used.
>
>Of course, there is a ton of issues that need to be worked out.

Sorry, I did not like to hijack the thread and good to know, that the 
other issues are also in mind.

>> I've installed a fresh Debian 8 a few months ago and it wasn't really
>> easy and especialy for beginners this stuff isn't manageable IMHO. Now
>> pulseaudio and speech-dispatcher are running in system mode and
>> everything is working well, but that kind of setup is not wanted for
>> security reasons.
>
>I am tempted to agree with you that we need far too much manual
>configuration interventions for certain accessibility features to
>cooperate, just by my own experience.  However, could you be a little
>bit more specific?  Particularily:
>
> * What sort of setup were you aiming to achieve?

I like to use the graphical environment, in my case Matte Desktop, and 
also a console screenreader with braille support, e.g. brltty or, in my 
case, sbl which can be downloaded on http://www.openblinux.de. the 
problem is the speech support which only is working well in Mate after a 
fresh installation, for the speech support in the console some things 
have to be configured which I will describe later.

> * What was particularily difficult to figure out?

IMHO the problem is that console screenreaders still can be used in user 
mode and have to be executed with root permissions, otherwise they don't 
work. For speech support for the console screenreaders also pulseaudio 
and speech-dispatcher have to be run in system mode. Installing the 
screenreader is not difficult and can be done easily via the package 
manager or by compiling it, but the way pulseaudio and speech-dispatcher 
have to be configured to work with the screenreader was not easy to 
figure out.

> * What did you have to change, from the default, to get what you want?

OK, here is a step by step description the way I did it, but I know 
there are other solutions like Halim allready wrote a few days ago:

1. Change the file /etc/default/speech-dispatcher to use the 
service in system mode:

RUN=yes

2. Change the file /etc/speech-dispatcher/speechd.conf to have the 
following variables set different to the default. I'm not sure, if all 
variables have to be set this way, but for me this settings are fine:

AddModule "espeak"   "sd_espeak"   "espeak.conf"

Because I want the German language to be used by espeak, I changed also 
the following variable accordingly:

LanguageDefaultModule "de"  "espeak"

3. To have pulseaudio running in system mode, insert or change the 
following things in /etc/pulse/daemon.conf:

daemonize = yes
allow-module-loading = no
allow-exit = no
system-instance = yes

4. To enable anonymous authentification to the pulseaudio daemon change 
the following setting in /etc/pulse/system.pa:

load-module module-native-protocol-unix auth-anonymous=1

5. Pulseaudio has to be started when the system is booted, so I put the 
following line in /etc/rc.local to do this automaticaly after the next 
reboot:

/usr/bin/pulseaudio

6. Ofcourse all needed packages, for example espeak and / or brltty or 
another console screenreader have to be installed and configured 
accordingly, to have speech support for console, the speech support for 
the graphical environment has been configured by the Debian installer 
already.

The following steps have to be performed to test the setup without 
booting the machine after all things described above have been done, but 
if you like to reboot speech support hopefully is working now.

Without a reboot do the following:

1. Stop speech-dispatcher and kill all still running processes which 
are not stopped by the start / stop script:

# service speech-dispatcher stop

2. Kill all pulseaudio processes:

# killall pulseaudio

3. Start pulseaudio with the new settings:

# pulseaudio

4. Start speech-dispatcher in system mode:

# service speech-dispatcher start

5. Restart the console screenreader to work with the settings needed for 
speech output, the speech support for the grafic mode still should work.

If no sound output is 

Pluseaudio, speech-dispatcher, and console + graphical screen readers

[Mario Lang]

Christian Schoepplein  writes:

> On Fri, Aug 28, 2015 at 12:33:41AM +0200, Samuel Thibault wrote:
>>As discussed during DebConf15, we target enabling the accessibility
>>stack by default.  I've studied that a bit more, here are my thoughts:
>
> Diskussing accessibility of Debian should not only be reduced to the 
> issues you mensioned, Samuel, there are a few more things that need to 
> be worked out, I think.

> For example the fact, that the way pulseaudio, speech-dispatcher and all 
> this stuff needs to be configured to work propperly, when orca and a 
> console screen reader is used.

Of course, there is a ton of issues that need to be worked out.
However, this thread is trying to deal with a rather specific topic,
namely, pushing for default enabled accessibility stacks in graphical
toolkits.  I have changed the subject of your thread, to keep matters
seprataed and avoid hijacking this other thread, which is actually also
important to work on.

> I've installed a fresh Debian 8 a few months ago and it wasn't really
> easy and especialy for beginners this stuff isn't manageable IMHO. Now
> pulseaudio and speech-dispatcher are running in system mode and
> everything is working well, but that kind of setup is not wanted for
> security reasons.

I am tempted to agree with you that we need far too much manual
configuration interventions for certain accessibility features to
cooperate, just by my own experience.  However, could you be a little
bit more specific?  Particularily:

 * What sort of setup were you aiming to achieve?
 * What was particularily difficult to figure out?
 * What did you have to change, from the default, to get what you want?

> So what about these things? Since pulseaudio is used as default for 
> sound output, the barriers using Debian with some setups have been 
> increased...

I agree, pulseaudio has been a source of many bugs in the user
experience.
I myself remember several incidents where ALSA soft mixing (which is,
AFAIU, supposed to be the default) failing and pulseaudio effectively
preventing a console ALSA application from gaining access to the sound
card.  I admit that I was not investigative enough in this situations,
and mostly just ended up "apt-get remove"'ing pulseaudio.  I know this
is no solution, and I am guilty of just giving up on that front in the past.

The Linux audio ecysystem is sort of a nightmare.  For a long time, all
we had was OSS (/dev/dsp).  Then came ALSA, which resulted in a long period of
programs either missing ALSA support, or ALSA support not quite
working.  That was the time when you still were suppposed to buy a
soundcard which supports hardware mixing, such that you could have
several programs talking to the soundcard at the same time.  At some
point, ALSA soft mixing support was mature enough that some
distributions started to enable it by default.  However, Linux audio has
other audio servers, like JACK, and later PulseAudio.  JACK is for the
pro audio people, a really nice realtime audio routing engine.  However,
if you use JACK, you also loose ALSA soft mixing because the JACK server
opens the soundcard in such a way that soft mixing can no longer work
(or at least, usually does).  Once JACK was really stable and doing a
lot of things, and many Linux audio applications added actual direct
support for it, the PulseAudio team decided to do yet another audio
server, specifically targeted for the Linux desktop (whatever that may
be).  The JACK people were not happy, but PulseAudio was somehow pushed
into existance.  So now a Linux audio application is more or less
supposed to implement direct support for ALSA, and support for two
different audio servers, JACK and PulseAido.  If they are portable
across UNIXes, they are likely to have /dev/dsp as well.  This is just
unrealistic, so the reality is, that most applications have a subset of
support for these mechanisms.
And some of the scenarios a user might encounter are just
incompatible.  Such as using JACK as the primary audio server
while using other legacy ALSA applications at the same time.
It also appeared to me in several occasions that PulseAudio does
sometimes make legacy ALSA applications unusable.

We need a pulseaudio expert to chime in on this.  Or someone from our
group needs to become one.

From POV of the Accessibility Team, our goals are easily summarized:

 * Configure whatever audio system is in use automatically, loading
   necessary modules, starting user-space support and ensuring the primary audio
   output channel levels are up, *not* muted.  This needs to happen
   independent from the desktop in use, and should also work if no graphical
   environment has been started at all.

 * Make sure that the speech synthesis backend of the screen reading
   solution does not block any other audio applications.  In the
   simplest case, desktop sounds should still work while the speech synthesizer 
is
   talking.

We need to identify common use cases which