[BRLTTY] introduction

[Dave Mielke]

[quoted lines by kendell clark on 2016/03/19 at 12:15 -0500]

>Ok, debug log is attached. 

eSpeak is initializing correctly. I see nothing in the log showing that brltty 
is trying to actually say something, though. This may be because that's its 
default behaviour. As a quick test to see if it can actually speak, try (with 
the keypad keyboard table enabled) pressing KPEnter+KP5. That'll explicitly 
tell it to speak the current line.

Another aspect of brltty's default behaviour is that it'll speak if no braille 
driver is running. What you may be experiencing, therefore, is that it's 
initially speaking up until, but not after, it manages to start a braille 
driver.

I'm guessing that you must be specifying: braille-driver auto,ba

The auto operand only works if it's specified by itself. That's why you're 
seeing a failure to load the "auto" braille driver library. Such a thing 
doesn't exist, but, since you're specifying more possible drivers, it's 
interpreting "auto" as an actual driver.

I wouldn't specify "ba" (the BrlAPI braille driver) as a driver to try within a 
default configuration. In fact, this is why a braille driver is eventually 
started, and, therefore, why you may be losing speech.

You're correct that you do want BrlAPI active, but not as a braille driver. 
What you want is BrlAPI to be active as a server, and that's the default 
behaviour. The BrlAPI braille driver is for communicating with a second 
instance of brltty.

>How would you run pulse audio as a system daemon? I've read up on this on the 
>arch wiki, but I've also heard there are some security risks with doing so. 

I've never looked up what their security worries are. One thing that I can 
think of, though, is that it may allow anyone to send audio to the speakers. 
Even worse might be that someone else could theoretically activate your 
microphone and listen in on you. I myself don't worry about such things, 
especially since control to Pulse Audio, even when running as a system daemon, 
is controlled by membership in the ulse-access user group.

>However, if this will make it easier to have brltty speak, I'll make it the 
>default on sonar. 

I tend to agree. Since they do have security concerns, though, you may want to 
look up what they are, and then to accompany your stuff with an appropriate 
warning.

>The idea is to be able to switch back and forth between the console and x 
>session without difficulty. 

This may require a bit of X reconfiguration since, by default, it starts its 
own Pulse Audio server. This creares a race condition between your system-wide 
daemon and the one X starts. If X starts its server first then yours won't be 
able to start. It'd be best, therefore, to explicitly tell X not to start its 
own.

More on you not having an actual braille display:

Brltty supports a couple of test braille drivers: XWindow [xw], and TTY {tt]. 
The XWindow driver creates a virtual braille display within an X window. The 
TTY driver creates a virtual braille display using your serial port.

If, therefore, you have either one of those (now ancient) serial port computer 
terminals or a second computer on which you can run a tool like minicom, you 
can emulate having an actual braille device.

-- 
Dave Mielke           | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario   | http://Mielke.cc/bible/
EMail: Dave at Mielke.cc | Canada  K2A 1H7   | http://FamilyRadio.org/