SpokenBoot

Differences between revisions 4 and 5
Revision 4 as of 2006-06-21 14:55:10
Size: 3608
Editor: ALagny-109-1-2-202
Comment: Rewrite implementation and change outstanding issues.
Revision 5 as of 2006-06-21 15:18:09
Size: 3652
Editor: ALagny-109-1-2-202
Comment: Added another outstanding issue.
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
 * '''Packages affected''': speech-dispatcher, speechd-up, lsb-base, initscripts, alsa-utils, alsa-lib  * '''Packages affected''': speech-dispatcher, speechd-up, lsb-base, initscripts, alsa-utils, alsa-lib, espeak
Line 45: Line 45:
 * Get espeak packaged and seeded.

Summary

Implement a mechanism to allow users to choose to receive spoken feedback on boot messages, at different levels of verbocity.

Rationale

Currently, the only way a blind computer user knows whether their system is functioning properly, is when the desktop loads, and the screen reader application they use loads and speaks a message. they have no way of knowing if there is something wrong with the boot process, or if a filesystem check has failed. If they don't hear any speech, they no something is wrong, but don't know what is wrong.

Use cases

  • Jane thinks that her computer is taking an unusually long time to boot up. She wants to be able to find out what her computer is doing while it boots the operating system.
  • Joel has recently installed a new server package, and is having trouble configuring it. He wants to know whether the server daemon, or any other boot process fails to load correctly when he restarts his system.
  • David thinks he has a filesystem problem. He decides to reboot his system to force a filesystem check. He wants to know whether the filesystem check is going to fail, and if so, wants to be able to rectify the problem.

Scope

This specification will discuss the loading of speech-dispatcher to provide software speech as early as possible, and the implementation of spoken feedback for the Ubuntu boot process.

Design

The Ubuntu boot process has already got mechanisms that can be leveraged to provide spoken boot information. Additionally, more spoken feedback, as well as more levels of verbocity can be reached by using the mechanisms provided by BootMessageLogging.

Implementation

  • Sound services would have to be loaded a lot earlier in the boot process, so that speech-dispatcher has a sound card to use in the event that one is needed. With a lightweight speech synthesizer such as espeak, the sound card, speech-dispatcher, and espeak can be placed into the initramfs. If the user desires to use a particular sound card for the speech output, the appropriate settings should also be written to a configuration file.
  • once the root and /usr filesystems have been mounted read-write, speech-dispatcher that was originally run from initramfs can be stopped, any logfile data can be transferred to the appropriate log files on the root/var filesystem, and speech-dispatcher can be restarted from the root filesystem.
  • The code used for BootMessageLogging can be extended to output any text logged to the spd-say utility. The spoken boot mechanism would have its own verbocity setting, with the same levels defined as in BootMessageLogging.

  • The script responsible for filesystem checking would be modified to load the speakup screen reader, in the event that a filesystem check has failed, and the user desired screen reader support for determining any problems. Once the user has completed the approrpriate tasks, the speakup screen reader would be unloaded after they exit the shell.

Code

Data preservation and migration

Outstanding issues

  • The SpeakupInclusion spec needs to be implemented before this spec can be useful.

  • speech-dispatcher and speechd-up need to be seeded.
  • Get espeak packaged and seeded.

BoF agenda and discussion


CategorySpec

SpokenBoot (last edited 2008-08-06 16:34:05 by localhost)