Re: Pluseaudio, speech-dispatcher, and console + graphical screen readers
Hi, On So, Okt 04, 2015 at 11:59:14 +0200, Christian Schoepplein wrote: > @Halim: Would you describe more detailed your setup with alsa please? > Wich steps did you perform after a fresh installation of Debian? First follow these stes described here: https://wiki.archlinux.org/index.php/PulseAudio#ALSA.2Fdmix_without_grabbing_hardware_device You have to switch to libao in speechd.conf and add your deskttopuser to group audio. HTH. Halim > Cheers, > > Schoepp > >
Re: Pluseaudio, speech-dispatcher, and console + graphical screen readers
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
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
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
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
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
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
> "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
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
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
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 given, check the mixer set
Re: Pluseaudio, speech-dispatcher, and console + graphical screen readers
Hi, On Mo, Aug 31, 2015 at 05:11:27 +0200, Mario Lang wrote: > We need to identify common use cases which currently have problems in > any of these areas. If you know of any, speak up. Common usecase? It should be possible to use a console screenreader with braille and speech running on the same machine with orca. I.ll try to describe my setup to avoid problems with pa: 1. in default.pa add the param device=dmix so pulseaudio can't open audio device with hw0,0 which would block all alsa output of other apps 2. set SPEECHD_ADDRESS variable and reconfigure speech-dispatcher to run in system mode. So orca or an other screenreader can use it at the same time. 3. Switch audiooutputmethod in speechd to libao and use libao'Äs alsa output backend. This works for me without any problems. HTH. Halim
Pluseaudio, speech-dispatcher, and console + graphical screen readers
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 currently have proble