This is a collection of free games for the blind that were created by Jim Kitchen of Chardon Ohio. Jim was an extraordinary person that dedicated the later years of his life to creating free games for the blind community. Over the years, his games were released by the comically fictitious Kitchen’s Inc. As Jim’s game collection grew, the joke became that he had programmed everything except the kitchen sink. With his passing, I present to you The Kitchen’s Sink, containing all 37 of his SAPI-speech-based Windows games and apps, in one fun-packed place! If you enjoy these games, please share them with others!
This is a collection of files that I’ve created for use with the Reaper Digital Audio Workstation software. These files will be of particular use the blind Reaper users, though others will undoubtedly find parts of them useful.
The following are excerpts from the included ReadMe file. Please refer to it for additional details.
The “Effects” folder contains two Reaper plug-ins that will help you work with some types of VST software instruments. The Hypersonic MIDI Controller makes it possible to select instrument voices and perform basic voice editing when used with Steinberg Hypersonic II. The General MIDI Controller makes it possible to select instrument voices and perform basic voice editing with both hardware MIDI modules and software instruments that respond to MIDI bank/patch change and other typical CC/RPN messages.
Some VST software instruments compatible with my MIDI controller plug-ins include: Steinberg Hypersonic, Edirol Hyper Canvas/Super Quartet/Orchestral, Native Instruments B4, E-Mu Proteus VX, Yamaha SXG50, and Re-FX Slayer. Please do not send me requests for download links for these instruments.
The “Presets” folder contains software instrument presets that can be useful in conjunction with some software instruments. For example, some software instruments, including Korg M1/Wavestation/Monopoly, and Native InstrumentsFM7/Pro53, already expose their internal instrument voice presets to Reaper. In the Effects window, with the software instrument selected, you’ll find two preset combo boxes: one combo box containing presets that you create on your own (or install from my collection) in Reaper, and another listing the plug-in’s built-in presets. Using the second combo box, you can easily scroll through the plug-in’s built-in instrument voice presets, but this is normally restricted to the first bank of presets. Many plug-ins contain additional banks of presets. For example, the Korg M1 has nearly 20 banks of individual voice presets, and another 20 banks of combination presets. With my presets installed, the first combo box in the Effects window can be used to select a bank of instrument voices. Once you’ve selected a bank, the second combo box will be updated to show the instrument voices that are available in that bank.
For other plug-ins, including RealGuitar/RealStrat, the software instrument normally provides no accessible way to switch between the plug-in’s presets. With my presets installed, you can switch between the presets of the plug-in by using the first combo box.
The “ProjectTemplates” and “TrackTemplates” folders contain starting points that will help set Reaper up for MIDI sequencing. When starting a new project, instead of creating a blank project, use the Softsynth Sequencing template. When adding tracks to a project for recording software instruments, instead of adding a blank track with CTRL+t, open the Insert Menu, select track template, and then softsynth. When using these templates, some basic settings will be made for you, such as the setup of a metronome with record count-in. Additionally, like other DAWs including SONAR/Garageband/Logic, you will be able to simply arrow to a track and play your keyboard in order to hear that track’s active software instrument. Without using these templates, it will be necessary for you to manually arm/disarm and manage track echo settings when switching between tracks.
Finally, the “Documentation” folder contains some notes that I’ve collected regarding Reaper. Of particular interest is my Reaper Key Guide. The Key Guide describes the keys that are used by ReaAccess. Rather than simply listing all of the available key commands, the Guide groups the commands by the type of function, and describes some patterns that can help you with memorizing them.
These are some Applescript scripts that I’ve created for VoiceOver.
- Say Power Status: If your Mac is running on battery power, this script announces the percent of the battery remaining, and the estimated run-time. If your Mac is running on mains/wall power, the battery percentage is reported, along with the estimated recharge time.
- Say The Time: Similar to Apple’s time script, but speaks using VoiceOver’s default synth.
- switch to Finder and open item chooser: The normal command for the Item Chooser is too hard to press for a frequently used command. Also, if the current app is “busy busy busy”, the Item Chooser won’t appear. This script first switches to the Finder, and then activates the Item Chooser.
To use these scripts, you need to save them somewhere on your computer, and assign a VoiceOver Keyboard Commander key to start them. Consider creating a location on your computer specifically for storing VoiceOver scripts, perhaps by creating a Scripts folder in your personal Library folder (~/Library/scripts). After copying the scripts to this location, open the VoiceOver Utility, go to Commanders, select Keyboard Commander, be sure the Keyboard Commander is enabled, and press the Add button to add a new Keyboard Commander assignment to the table.
Check out my page on SoundCloud to hear a few experimental tracks and demos that I’ve created with the different equipment that I use.
I’m writing this post to provide some additional background information about the Talking Windows Pre-installation Environment (TWPE) project, and to tap the collective brainpower of the community for overcoming some of the remaining limitations. If you have feedback about this post, please send an email to email@example.com, or, better still, write to @bryansmart on Twitter.
Overview of Windows Pre-installation Environment
Windows Pre-installation Environment (often abbreviated WinPE), is a minimal version of Windows. The Pre-installation Environment portion of the name is due to the typical purpose of WinPE: to serve as a minimal operating system for use by Windows installation/setup and recovery features. When installing Windows, the Windows installation disk normally loads WinPE, and then loads Windows Setup.
Windows PE is used for tasks other than installing Windows, though. Many computer manufacturers create special partitions on the computers hard drive, or else provide special disks, to restore the computer to the state that it was in when it originally was purchased. In most cases, this recovery software uses WinPE as a basic operating system. Many companies that make hard disk imaging software also use WinPE as the operating system for powering their restore disks.
Microsoft distributes WinPE as freeware. That means that it is free to use and to share, but it can not be sold. The license for WinPE also includes restrictions that prevent it from being used for commercial products.
WinPE also contains many technical limitations. It is not able to operate in a multiple user mode. It will not run for extended periods of time without rebooting. It is also missing many components normally found in Windows. Most significantly for the blind user, the version of WinPE found on Windows installation disks does not include most components required for sound, drivers for sound devices, Microsoft text-to-speech voices, or Narrator.
For more about WinPE, go here.
Overview of WinBuilder
WinBuilder is a system for creating customized Windows boot disks. Since customizing WinPE to add any particular feature can involve many steps, including copying several files to multiple locations, modifying configuration settings in INI files, modifying the registry, and others, users on the WinBuilder Forum collaborate by creating scripts to implement each feature. For example, a script might add a system component like DirectX or an application like Firefox. Scripts also perform tasks related to the building of an image, such as copying the base WinPE files from a Windows install disk, creating an ISO of the modified files, or setting up a boot loader.
Scripts for performing various tasks are combined in to WinBuilder projects. WinBuilder projects produce bootable WinPE disks or disk images as their products. Many WinBuilder projects are available. Most WinBuilder projects are intended for tasks such as removing viruses and OS repair. Most projects do not include sound support.
Problems and Solutions
As is the case with many blind Windows users, when setting up Windows, I’d either use an unattended setup file, or else install over an existing copy of Windows. Neither of these approaches work particularly well.
Unattended setup files provide no spoken feedback during installation, and so the process is to usually start setup, wait half an hour, and hope something happens. If nothing happened, you must carefully check over your file, consider what might be wrong, make your changes, and wait again. Even if you have an unattended setup file that you know to be valid, it is difficult to create unattended setup files that handle atypical situations, such as computers with multiple hard drive partitions, storage devices that require drivers before they can be accessed, and so on.
You can always install Windows over itself. In this approach, the user starts Windows, inserts the Windows DVD, and runs setup. This approach has the benefit of speech feedback, but it includes limitations. Since you’re running setup from an active operating system, you can’t repartition the hard drive. It also isn’t possible to install Windows for a different architecture: for example, if you’re using 32-bit Windows, you can’t re-install as 64-bit Windows. Finally, you can’t install an older OS. If you’re running Windows 8, and wish to downgrade the computer to Windows 7, setup will not permit it.
I began this project to remove all of the above limitations. My goal when beginning this project was to create a simple talking WinPE desktop that could be used to install or repair Windows. If a talking version of WinPE was available, then a blind user could start this talking WinPE boot disk and proceed to run Windows setup from the stock Windows install disk without any further modifications.
Creating the Talking Windows Pre-installation Environment (TWPE)
When researching possibilities for creating WinPE boot disks, I quickly discovered WinBuilder. Many WinBuilder projects were listed on the WinBuilder forums, but few of them had any sound support, and I wasn’t sure how I would easily get Narrator or NVDA integrated.
I eventually stumbled across a thread where some blind users had been asking Al_jo, an expert forum member/project creator, to help with NVDA support that briefly had been present in an old WinBuilder project. After that work didn’t lead to any success, Al_jo decided to simply add NVDA support to one of the projects that he maintained. You can read more about Al_jo’s Win7PENVDA project in this thread.
I attempted to use Al_jo’s project, but ran in to some issues. First, his projects were only based on the 32-bit version of WinPE. This was fine for the project’s original purpose of antivirus/OS repair, but wouldn’t permit 64-bit Windows to be installed. Second, the project was full of apps that were mostly inaccessible to NVDA. Third, the WinBuilder system isn’t particularly screen reader friendly: NVDA can’t see check boxes in the scripts tree view, most controls don’t support keyboard navigation, etc. I knew that, if I simply told people about this project, beyond the complexity of getting it to build at all, the screen reader issues would mean that most novices wouldn’t have any success. Further, most people wouldn’t want to tweak and re-tweak their boot disk; they would just want something that they could burn to media and use to install/repair Windows.
TWPE Release 1
Originally, I wanted to distribute both a 32-bit and a 64-bit boot disk. The user would simply boot the disk that matched the architecture of the Windows that they wished to install, and they would then be able to run setup.exe from the original Windows install disk. Even though TWPE is based on Windows 7, it would still be able to install Vista, Windows 7, Windows 8/8.1, Server 2003, Server 2008, etc.
The 32-bit boot disk was relatively simple to create. I removed anything from Al_jo’s original project that wasn’t accessible, added a large set of audio drivers, and updated NVDA.
The 64-bit boot disk was a greater challenge. Al_jo was able to assist me by creating a 64-bit version of his WinBuilder project. However, many computers are still unable to start Windows setup from the 64-bit boot disk. When they attempt it, they receive an error indicating that there has been an unknown error when initializing COM. COM is certainly present on the 64-bit boot disk: NVDA uses it extensively.
I’ve asked Al_jo to assist with troubleshooting this error, but he says that he is unable to reproduce it. Boot disks that he builds with his 64-bit WinBuilder project are able to successfully start Windows setup. Until I can resolve this problem, I won’t be able to distribute a 64-bit boot disk. It isn’t practical to request that Al_jo build each release and send an ISO, as he has other projects requiring his attention.
To temporarily work around the problems with the 64-bit boot disk, I created two disk images: a “basic” and a “mega”. The basic disk is largely the same as the 32-bit boot disk from release 1, although with additional drivers. The mega disk includes a modified version of the 32-bit setup for Windows 7. I’ve modified the install.wim so that, while the installer itself is 32-bit, it is able to install any of the images needed for the various editions of Windows 7, both 32-bit and 64-bit.
The modifications to the mega disk make it possible for a blind user to independently install any edition of Windows 7, but it is a poor solution. Most importantly, the mega disk only contains an English version of Windows 7. As with release 1, it is still possible to install any language of 32-bit Windows by simply inserting the install disk and running setup, but installing 64-bit editions won’t be possible. Similarly, it is possible to install the 32-bit version of Windows 8/8.1, but not the 64-bit edition.
I’ve tried everything that I can think of to build Al_jo’s 64-bit boot disk project. I’ve followed his setup to the letter: same host OS, same source media, same file locations, etc, but the version produced by my WinBuilder always results in the COM error when I run Windows setup. He has been helpful, but has run out of suggestions for me. WinBuilder projects are based on poorly documented scripts that are written in an atypical language, and I’ve not had luck in finding the flaw in the logic.
The reality in 2013 is that most people are now running 64-bit versions of Windows. Until we have a 64-bit boot disk, it won’t be possible for people to simply install any version of Windows that they have on hand by starting a talking boot disk and inserting their Windows DVD. I’m posting this background info here, along with everything that I have gathered regarding WinBuilder, in the hopes that some other smart people out there will help figure out what is wrong.
There are other features that I plan to add to these boot disks, including free tools for drive imaging and OS repair. However, the disks need to be able to perform their basic function (installing Windows), before much further time is spent on mods to either the 32-bit or the 64-bit WinBuilder projects
First, here are the download links for the current state of things:
Next, here are the original WinBuilder projects from Al_jo:
Remember that, to build either of these, you’ll need an ISO of Windows 7 32-bit for the 32-bit project, and 64-bit for the 64-bit project.
Though it isn’t the exact same WinBuilder project, this guide contains the instructions for the build process. Sorry if the link doesn’t work, but Al_jo’s site goes up and down.
Note: If you use WinBuilder with NVDA, you will not see the check boxes in the scripts tree view. JAWS recognizes the check boxes. I have no info about the status of other screen readers.
To build the project, you must press the play button in the toolbar at the top of the window. If you’re using JAWS, you’ll need your JAWS cursor. The play button is the first graphic in the line immediately under the menu bar. It is also possible to press this button with NVDA object nav: it can be found at the same nav level as the tree view.
I look forward to hearing from those of you that attempt to build the 64-bit project. Hopefully, you’ll figure out what it is that I’m doing wrong.
Blind Windows users now have a free way to independently install Windows and repair broken Windows installations. Check it out here.
UPDATE 7/21/2013: Several people previously had trouble with this post due to confusion over WordPress’s annoying automatic smart quotes substitution. I’ve figured out how to disable that behavior now, so all examples should be used exactly as shown. Also added info about newer versions of VMware and host operating systems.
Anyone that uses vmWare Workstation on Windows and vmWare Fusion on the Mac together with a screen reader has probably noticed that the screen reader’s speech doesn’t respond quickly when they press key commands. Since a common behavior of screen reader users is to rapidly skim through information by repeatedly pressing a screen reader’s navigation commands, the slow response of the screen reader’s speech inside a virtual machine means that the guest operating system seems sluggish.
vmWare provides sound output for the guest operating system by simulating a virtual sound device inside the virtual machine. In the host’s operating system, vmWare uses sound in a similar manner to any other application. The vmWare application is, therefore, a proxy between the virtual sound device and the actual sound capabilities of your computer. Since vmWare is an application, it has to compete with other open applications for your computer’s resources. If multiple virtual machines are open, those virtual machines are also competing for limited resources. If the resource needs of an app other than vmWare, or another virtual machine, experiences a sudden spike, vmWare might temporarily be unable to pass sound between the virtual sound device and your computer’s physical sound device. In this situation, sound output from the virtual machine could seem to pop and click, or sound output could briefly stop altogether.
To improve this situation, vmWare buffers sound between the virtual and the physical sound devices. A buffer is an area of the computer’s memory that holds a fragment of information (sound, in this case). When a virtual machine plays sound, instead of passing sound directly between the virtual (guest) and physical (host) sound devices, the guest side of the connection places sound in to a buffer, the buffer is first allowed to fill with sound data, and, once the buffer is full, the host side begins to remove sound information from the buffer and pass it along to the physical sound device. Under normal conditions, the guest side will keep the buffer full by placing new sound information in to the buffer only as fast as the host side removes sound information. If the computer’s resources suddenly become limited, the guest side might not be able to continue placing new sound in to the buffer, but the host side can continue to remove and play sound that has already been accumulated in the buffer. Once resources are available again, the guest side can catch up by quickly placing new sound information in to the buffer until the buffer is full again. A similar process happens in reverse when a virtual machine records sound from a physical sound device.
The buffer prevents brief shortages of computing resources from causing pops and clicks in the sound of the virtual machine, but it also places all of a virtual machine’s sound on a delay. If the buffer were removed, then even brief limitations of computing resources on the host computer would cause the virtual machine’s audio to pop and click. If the buffer were extremely small, then it only would contain enough sound information to compensate for brief resource limitations. If the buffer were extremely large, then it could continue to provide glitch-free sound, even under long periods of limited computing resources, but the sound between the virtual and physical sound devices will be on an extremely long delay. The goal is to find a good compromise. The vmWare developers use a buffer that provides a fairly short delay, while being able to smooth over most brief resource limitations. Their priority is to produce glitch-free sound, not to provide the shortest delay. We, of course, have different goals.
Setting the buffer size
If you haven’t guessed by now, you’ll be making this situation better by adjusting the size of the buffer that vmWare uses for sound. Remember that the vmWare developers set the buffer size the way that it is by default to provide glitch-free audio. If you change the buffer size, you’ll probably start to notice glitches. If your computer is fast, and you aren’t using too many open applications at once, then a small buffer will result in only occasional glitches while dramatically reducing the delay. Computers have dramatically different amounts of resources, and run a wide mix of applications, so you’ll need to experiment in order to determine how small you can set the sound buffer before the glitches become too frequent to tolerate.
WARNING! Incorrectly editing your virtual machine’s configuration file can cause it to become unable to start. The easiest way to avoid this problem is to create a snapshot of the virtual machine prior to editing the configuration file. You will then easily be able to restore the snapshot to un-do any changes that you make to the configuration file if you experience problems. You can quickly access the snapshots window on VMware Workstation for Windows by pressing CTRL+m, and can access the snapshots window on VMware Fusion for Mac by pressing Command+s.
Before continuing, please be sure that your virtual machine is completely powered off. Simply suspending the virtual machine is not sufficient, as the following changes will modify the hardware of the virtual machine.
To change the size of the sound buffer used by vmWare, you must manually edit a configuration file. Each virtual machine includes a file with the VMX extension that specifies the way that the virtual machine will operate. On Windows, the VMX file will be located in the same folder as the other files used by a virtual machine. On the Mac, all of a virtual machine’s files are contained inside a bundle, and you must control-click the bundle and select “Show Package Contents” to display them. You can open the VMX file with any text editor, such as Notepad on Windows or TextEdit on the Mac. If you need further help, the vmWare knowledge base offers Tips for Editing a VMX File.
In the VMX file, you’ll find lines that look like:
category.optionName = "value"
Category selects a group of options, such as “sound” for the virtual sound device, “usb” for the virtual USB controller, etc. After the “.” is the name of the option to set. After the “=”, the value to use for the option is entered, and should be in quotes.
Disabling HD Audio
Starting with Workstation 8 on Windows and Fusion 4 on Mac, vmWare provides a new virtual sound device for some operating systems. This device simulates a RealTek ALC888 sound device. This new “HDAudio” device is a better virtual sound device in many ways. It even uses smaller sound buffers by default on Mac and Linux when compared to the older virtual sound device. However, its buffers are not as customizable as the older virtual sound device, and so I suggest that you not use it if extreme low latency is your goal.
To use the older virtual sound device, make the following changes to your VMX file.
By default, vmWare will automatically select the best virtual sound device for the guest operating system. We need manual control of this selection. Find the following line in your VMX file.
sound.autoDetect = "TRUE"
Change the “autoDetect” setting to false. Don’t forget to keep the surrounding quotes.
Next, we need to manually set the virtual sound device type. Look for a line in your VMX file similar to:
sound.virtualDev = "hdaudio"
Change it to:
sound.virtualDev = "es1371"
Booting With the New Sound Device
Now, close the VMX file and start your virtual machine. Once Windows starts, it should automatically detect the new sound device and load the drivers for it. If Windows doesn’t load the correct drivers, then you can get them to load by re-installing the VMware tools on the virtual machine. The option for re-installing the VMware tools can typically be found in the Power menu of VMware Workstation and VMware Fusion.
If your virtual machine fails to start, then you may have made a mistake while editing the VMX file. Use the snapshots window to restore the virtual machine to the state that it was in prior to this procedure, and try again.
Once Windows has started, and the new sound device has been detected, shut down Windows and re-open the VMX file.
Setting Play Buffer Size
Finally, we can set the buffer size for the virtual sound device. You probably won’t have a line in your VMX file already to do this, so you’ll need to add it. Be sure to check for one, though, as having multiple entries could cause the buffer to perform in an unexpected way.
pciSound.playBuffer = "200"
200 is the size of the buffer in milliseconds. The default size is 200 on Windows and Mac, and 100 on other host operating systems. Try using a smaller value. I’ve found that most modern Windows and Mac computers can handle a size of 30 without difficulty.
The above option adjusts the size of the playback buffer (the sound that is produced by the virtual machine). There is a separate recording buffer (sound that is recorded by the virtual machine). Compared with the default play buffer, the default record buffer is huge (more than 1 second). I’ve extensively searched online, and have even contacted vmWare directly, but, as far as anyone has been able to determine, there isn’t an option for adjusting the size of the record buffer. If you’re using conferencing applications, for example, inside a virtual machine, you’ll notice a long lag between when you say something, and when the other participants hear it. Together with the existing lag that is present in most wide area voice-over-IP situations, the total lag is substantial.
If it is important for you to reduce the size of the record buffer, then I suggest that you use the newer HD Audio virtual sound device, as its default record buffer is smaller. However, by using the HD Audio virtual sound device, you give up the capability of adjusting the size of the play buffer.
Controlling HD Audio Buffer Size
I recently received some info from vmWare development regarding the buffer sizes for the HD Audio virtual sound device. I was told that the buffer sizes are set to 80 msecs when running on a Mac host, 200 msecs when running on a Windows host, and 100 msecs for Linux and other hosts. The huge latency on Windows means that Windows users will almost always prefer the older virtual sound device.
Supposedly, the size of the buffers used by the HD Audio virtual sound device can be changed. vmWare development told me about the following VMX entry:
sound.bufferTime = "100"
100 is the buffer time in msecs.
I’ve tried this setting with vmWare Fusion on the Mac, but it doesn’t seem to have any effect. I haven’t had a chance to try it out on Windows yet.
In general, the dev from vmWare acknowledged that the HD Audio implementation is rough in many places, and that they are aware of the latency problems. Given that the HD Audio support is extremely new, both some problems, as well as future improvements, are expected.
Other HD Audio Options
There are other options for adjusting the behavior of the virtual sound devices. Most of them are listed here. Some options on that site are for the HD Audio device, some are for the ES1371 device, and some are even for the ancient SoundBlaster 16 device that was used in extremely early versions of vmWare. vmWare has never published a list, and doesn’t even seem to have internal documentation for them in many cases beyond source code comments. All of the known options have been discovered by viewing VMX files that are generated by vmWare products, through a few references in the vmWare knowledge base, and through communication with people from vmWare development and support. The situation is a mess, but will hopefully improve as the HD Audio support matures.
USB Audio Support
If none of the options in this article are able to meet your needs, be aware that there is always the option of using a USB sound device with your virtual machine. Recent versions of Workstation and Fusion have extremely good USB support. Most any USB sound device, including conferencing headsets, work well, and perform with latency as low as if they had been connected directly to a physical computer running Windows. Even some high-end multi-channel USB sound devices will work reasonably well with virtual machines.
I’m a long-time paying user of VMware products in both my personal and work life. The sound situation has improved quite a lot since I started using VMware over 10 years ago. I’ve had to regrettably harass VMware technical support on several occasions about this issue in particular, and I’m confident that this is all of the info that it is possible for VMware to provide us with for now. VMware development knows about the latency problems, but I’m unable to guess what sort of improvements they’ll be able to make in the future. VMware makes only a small portion of its income from desktop virtualization. Cloud is their primary focus now, and sound support is practically unused in cloud deployments of VMware.
If you’ve come across this post and have other observations or tricks for improving audio latency for vmWare virtual machines, please post a comment or contact me.