Gnome, Accessibility and Sound

From time to time, my optimism asserts itself and I decide to start off on some software upgrade project. "Software has evolved; this will go reasonably well and I'll be happy at the end," I think. It never works. A few weeks ago I wrote and said that I was moving to Virtualbox as a virtualization solution. That went well enough on my desktop that I decided to try and bring that to my laptop. As part of playing with Virtualbox, I've come to the conclusiong that Orca, the Gnome screen reader is either useful enough that I could get some value out of Gnome, or will be there in a small number of months. So, I decided to move from console land to X.

Most of my work is in Emacs or in a terminal buffer within Emacs. I use Emacspeak as a screen reader for Emacs; it is a collection of lisp that interprets calls to output text and makes sure speech is also output. That's not going to change all that much. I'll probably use some Gnome applications, but I expect most of what I do will still be in Emacs. In particular, I'm not planning to drop Gnus as my mail reader--although I'm considering using Evolution for some things.

So, the desired final result is Emacs, Gnome and Virtualbox running under X. There will be three screen readers: Orca for Gnome, Emacspeak for Emacs and Window Eyes for Windows. X can handle that, so what's the big deal? Well, the Linux sound drivers can't always handle that. It turn out that with modern kernels, libraries and hardware, ALSA can do fine too. However only one OSS application can have the sound card opened at the same time. If any ALSA applications have the sound card open, then no OSS applications can have the sound card open. I'm using Flite as a backend speech synthesizer for Emacspeak; unfortunately, it is built against OSS rather than ALSA. However it's good and keeps the sound card open only for very short times. Orca uses Espeak (or at least that seems the best option), which uses ALSA. However Espeak also keeps the sound card open for short periods of time. The astute reader may notice some missing information at this point.

Of course with any such project there is bound to be some pre-yaks to shave before you actually get down to work. In my case, that was dvorak on X. Gnome has this nice keyboard preferences applet that lets you choose your keyboard layout. It let me choose dvorak just fine. But the fine folks at x.org decided that the dvorak layout should not remap the control keys. So, if you hit the key to the right of 'a', you get 'o', but if you hold down control and hit the same key ou get 'C-s'. That might actually be an improvement except that the Linux console map, Windows and the Mac all do it differently. So I learned dvorak with the control keys remapped and that's how my finger macros work. There seems to be no way to do this right short of mucking with the xkb symbol maps. For some reason I have two sets of xkb rules, one in /etc/X11 and one in /usr/share. Different tools seem to use different sets and they work differently. I did get it working, although not in a manner that will be preserved across upgrades. The dvorak yak had somewhat more hair than expected. The Orca laptop layout uses '7-9', 'u-o', 'j-l'. That is not actually improved by the dvorak translation. So I decided to remap the keys. Unfortunately, the keyboard layout dialogue for Orca sorts things by the key position on the keyboard! So, as you change keys, the display resorts and it is challenging to figure out what remains to be done.

Everything worked until I added Virtualbox to the mix. Well everything except for gdm, but I haven't figured that out yet. Virtualbox is an ALSA application. It holds the sound card open the entire time it's running. Oops.

So, there are two approaches I can think of. I can cause Flite to use ALSA or I can use something other than Flite. Now, in theory, Emacspeak also supports Espeak. I decided to try and go down that road. However it seems to depend on some TCL shared library that is no where to be found. It's apparently in the Emacspeak subversion repository but not actually shipping in the releases. Hmm, let's go take a look at Flite and ALSA support. Ah, promising. What's this au_alsa.c? Ah, that's no good. It seems to be two or three ALSA APIs out of date and doesn't seem to work. Let's see if there is a new version of Flite. O, there is. And look! They removed ALSA support completely! So back to that Espeak server. O, hey, look. It doesn't compile when you check it out of source. In fact it can't possibly have ever compiled with these options. Who builds their software -ansi -pedantic anyway? It does sort of work, but it leaves a lot to be desired. The way it says punctuation is kind of unfortunate, and it's missing a bunch of little beeps that are an important part of how Emacspeak communicates. I'm not entirely sure whether I want to live with this or write ALSA support for Flite.

In other news, the state of Gnome phone sync support is really incredibly horrid.

(no subject)

That wasnot as hard as I thought . I now have a ALSA audio driver for flite. There is something not quite the same about the sound output, but it does seem to work and I have Orca, Emacspeak and Windows all playing sound. And I can listen to music while coding, which is something I've wanted for years. Hmm. should I try and do something really scary like try to get all this working with a bluetooth headset?

I was somewhat scared by the ALSA API until I realized that there is snd_pcm_set_params and that you can mostly ignore the configuration spaces.