Provide a functional console screen reader.

Whilst Vinux does its best to provide an easy to set up, easy to use GUi Ubuntu based Linux system, there are users who still wish, and in some cases, prefer, to use the text console as their environment of choice. In previous versions of Vinux, there have been some problems with properly setting up software speech to work in the text console.

Traditionally, console screen reader and speech solutions ran as system services, either as a system user, or as root. This worked well enough, although there were security issues with such a setup. However with such a small number of users using this software, such issues were not as concerning, and in many if not all cases, nobody was aware of such security issues.

Since then, much work has been done on the graphical desktop, and security has been at the forefront of developers' minds. As a result, any service or application that a user may require is designed to work with as few privileges as possible, and great care is taken to make sure that system level access is acquired only when absolutely necessary. This has also allowed more flexible access to hardware, allowing multiple users to be logged into a system at once.

Enter ConsoleKit. ConsoleKit is designed to manage access to system hardware between multiple logged in users. So, when you log into a GNOME session, ConsoleKit makes sure your user has access to the display, keyboard, mouse, sound card, and other hardware that you might need during your session. If you switch to a text console terminal, any program that you may have running that is trying to play audio for example, will lose access to the sound card, unless you are logged into that text console terminal.

Unfortunately, this breaks console screen reader access to the sound card at the system level. It is possible for a user to run the screen reader and speech synthesizer processes as their user, and use the system from the console. However, this does not allow the user to be able to successfully log in via text login shell, as there is no access to the sound card.

Amongst all these goings on, pulseaudio was developed, and like many other desktop software services, it was developed to fit into the user session model, running as the user, and acquiring necessary realtime priority privileges via system service only when necessary.

Whilst PulseAudio isn't strictly necessary for screen reader use, it is more convenient, and in most cases, uses a cleaner resampling method to handle multiple audio streams at different sample rates. ALSA also has a rather complicated API, and stability issues have arrissen when attempting to code ALSA support for speech synthesis output, as a result of using parts of the ALSA API together that otherwise should not be.

PulseAudio can be run as a system service, however it looses some performance benefits that are otherwise available when running as the user. Such performance benefits are disabled due to security issues when working with pulseaudio accross user/group boundaries. Any user who needs to play audio via PulseAudio needs to be a member of a pre-defined group that PulseAudio is a member of. One advantage of running PulseAudio as a system service is that ConsoleKit restrictions no longer apply, so a screen reader and speech synthesizer can run at the system level and can access audio via PulseAudio, which is itself running as a system service.

Solving the screen reader speech synthesizer access problem can be solved in one of 2 ways.

1. We provide a utility that handles switching PulseAudio between user and system mode. This utility will also enable speakup/speechd-up for the console at the same time as PulseAudio is switched to system mode. We can also make sure that the first user account is added to the pulse-access group at install time. This solution is the quickest and easiest to implement, however as noted above, PulseAudio performance is impacted somewhat, and other benefits for multi-user systems such as individual volume control and audio output settings are lost.
2. We create a special system user to provide an isolated environment to run speech-dup, speech-dispatcher, and PulseAudio for text console login. We then extend ConsoleKit to allow this user access to speakup, and audio hardware when there is no user logged in on the currently active virtual terminal. We also extend speechd-up to be ConsoleKit aware. We finally set up speech-dispatcher and speechd-up to run in a user session once the user logs into a text console environment.

One issue with the second solution is code maintenance and getting code upstream. ConsoleKit is no longer maintained upstream, and will be replaced with logind from the systemd suite of utilities in Ubuntu 12.10 and beyond (No Ubuntu is not switching to SystemD wholesale). So if we decide to implement solution 2 for Vinux 4.0 based on precise, we will have to extend ConsoleKit now, and then re-implement this same solution for future Vinux releases. The upshot of this is that we can get the code upstream, and then we no longer need to maintain the code ourselves, at least not on our own.