Sound Blaster 16 on VMware Workstation 15.5 and VMware Fusion 11.5

Version 1

    Emulation of the Creative Labs Sound Blaster 16 (SB16) sound card is now available on VMware Workstation for Windows hosts, VMware Workstation for Linux hosts, and VMware Fusion for macOS hosts.  The Sound Blaster 16 emulation is vastly improved from Workstation releases prior to Workstation 15.5, and is entirely new for VMware Fusion 11.5.

     

    Note: Despite these improvements, the Sound Blaster 16 is a legacy device; Ongoing development and support is not guaranteed.

     

    Improvements in this Release

    • For the first time, VMware Fusion on macOS hosts can emulate the Sound Blaster 16.
    • Workstation has expanded capabilities on Linux hosts through the addition of ALSA and PulseAudio support to the Sound Blaster 16.  OSS support has been deprecated.
    • The emulated Sound Blaster 16 is now capable of simultaneous PCM/Wave and Adlib FM music output on all supported hosts.
    • The emulated Sound Blaster 16 now includes an experimental MIDI output which is capable of passing MIDI messages through to the host and/or to an external MIDI synthesizer.

     

    Activating any of these features requires the use of a configuration option (now quite inaccurately named):

     

       sound.opl3.enabled = "TRUE"

     

    Check if your VM already has a config option for sound.virtualDev.  If one is not present, create it, otherwise edit the existing entry and set:

     

       sound.virtualDev = "sb16"

     

    Known Shortcomings

    Please be aware that MS-DOS programs and games use a wide variety of techniques to detect and manage sound devices, and it is not possible to guarantee compatibility or functionality when used with the emulated Sound Blaster 16.  Programs may vary in their support for hardware music and sound devices.

     

    Shortcomings in PCM/Wave Playback and Recording

    • Some legacy/compatibility commands and formats used by the Sound Blaster, Sound Blaster Pro and Sound Blaster Pro 2 are not implemented in the emulated Sound Blaster 16; Programs which pre-date the SB16 or do not recognize the sound card as an SB16 might be unable to play audio or might fail in other ways.
      • Known failures: Brøderbund Software's Prince of Persia.
    • The timing of internal events related to playback and recording might differ from that of a physical SB16.  If this timing is wrong, the likely result will be sound playback/recording with repeating ticks or clicks throughout.
      • Known failures: Future Crew's Unreal Demo, Windows 95 playing/recording at 22 kHz or higher.
    • Audio latency for playback and recording is not optimal and is most likely higher than a physical Sound Blaster 16.  It should be adequate for casual use.

     

    Shortcomings in Adlib/OPL3 FM Music Synthesizer

    • Rhythm instruments are not implemented.

     

    Shortcomings in Audio Mixer Controls

    • Legacy/compatibility mixer controls are not implemented.  Programs which pre-date the SB16 or do not recognize the sound card as an SB16 might be unable to adjust mixer levels.
    • PC Speaker level control is not implemented.
    • Bass/Treble controls are not implemented.
    • Hardware audio loopback is not implemented, so it is not possible to use the Sound Blaster 16 to record its own output.

     

    New Feature: MIDI Output

    This facility is double-super-duper-experimental and is disabled by default, but is also double-super-duper-cool.  Remember that MIDI dongle that could plug into the Sound Blaster 16's Game Port?  This is that.  To try it out, edit a powered-off VM's configuration file to add

     

    sound.mpu401.host = "TRUE"

     

    Caveats:

    • Only output is supported; There is no capability for the emulated Sound Blaster 16 device's MIDI IN port to receive MIDI data from the host.  Any MIDI SysEx messages originating from the VM are not forwarded to the host; They will be ignored.  As a result, the MIDI output capability will be usable for music playback from games and other programs inside the VM, but is unlikely to meet more complex needs.
    • MPU-401 MIDI UART mode is the only supported output mode.  Thankfully it is also by far the most widely-supported mode.
      • The Sound Blaster 16's legacy SB-MIDI mode is not implemented.
      • MPU-401 Intelligent mode is not available on a physical SB16 and is also not available in the SB16 emulation.

     

    Behavior of MIDI Port during Connect/Disconnect, Suspend/Resume

    The SB16 MIDI output will only attempt to connect to a host MIDI service at the moment that the virtual machine is powered on or resumed, or at the moment the Sound Card is toggled to Connected in the Workstation or Fusion user interface.  If no host MIDI device is available at that time, the SB16 MIDI output will remain disconnected.  If the host MIDI device becomes unavailable during use, the SB16 MIDI output will be disconnected and no attempt will be made to reconnect.  As a result, if a software synthesizer (see below) is terminated and relaunched, it might be necessary to take additional actions (e.g. disconnecting and reconnecting the Sound Card, and/or running aconnect again on a Linux host) before MIDI output is active.

     

    Suspending or powering off a VM will not perform any "cleanup" of the MIDI output; If the MIDI output is in active use, lingering notes are likely.  It is therefore recommended that the VM be put into a state where it is not actively using its MIDI output before it is suspended or powered off.  Similarly, resuming a VM will not attempt to restore the prior state of the host MIDI device.  If the host MIDI device's state has been changed since the VM was suspended, results will be unpredictable.

     

    Configuring your host to handle MIDI output

    Using MIDI output with VMware Workstation on a Microsoft Windows host

    VMware Workstation will send MIDI messages to the default host MIDI device, which is likely to be the Microsoft GS Wavetable Synthesizer.  Recent versions of Windows appear to require a 3rd-party tool to direct the MIDI output to any other MIDI device.

     

    Using MIDI output with VMware Workstation on a Linux host

    VMware Workstation will send MIDI messages to an ALSA virtual rawmidi device created for that purpose.  After the VM is powered on, you may need to use aconnect command on the host to direct the MIDI messages output by the virtual machine to a software synthesizer or external MIDI device.  Refer to the manpage for aconnect for further details.

     

    Other MIDI programming interfaces are not presently supported.

     

    One option for rendering MIDI output into audible music is FluidSynth.  As usual with Linux, you have an abundance of ways to configure things; You may need to refer to documentation from your Linux distribution or from the FluidSynth, ALSA or PulseAudio projects.  You might even need to refer to the source...

     

    Here is how it works on my Debian 9 amd64 host:

     

    1. If you haven't already done so, install the fluidsynth and fluid-soundfont-gm packages as follows:

      sudo apt-get install fluidsynth fluid-soundfont-gm

    2. To launch the software synthesizer, retrieving its inputs from the ALSA sequencer and rendering audio to the host's PulseAudio sound server:

      fluidsynth -m alsa_seq -a pulseaudio /usr/share/sounds/sf2/FluidR3_GM.sf2

    3. Power on your VM.
    4. Run aconnect -l to see which sequencer clients are running.  In my case, it looks like this:

      dariusd@host:~$ aconnect -l
      client 0: 'System' [type=kernel]
          0 'Timer           '
          1 'Announce        '
      client 14: 'Midi Through' [type=kernel]
          0 'Midi Through Port-0'
      client 128: 'TiMidity' [type=user,pid=622]
          0 'TiMidity port 0 '
          1 'TiMidity port 1 '
          2 'TiMidity port 2 '
          3 'TiMidity port 3 '
      client 129: 'FLUID Synth (2143)' [type=user,pid=2143]
          0 'Synth input port (2143:0)'
      client 130: 'Client-130' [type=user,pid=3127]
          0 'Virtual RawMIDI '
      dariusd@host:~$

      Client 129 is FluidSynth ready to receive MIDI input, and client 130 is the SB16 MIDI output from the virtual machine.  To connect them, specify the VM's output port first and the synthesizer's input second in the following command:

      aconnect 130 129

    5. Run your SB16 MIDI program inside the virtual machine.  FluidSynth will render the MIDI to audio.

     

    Note that aconnect -l will show the current connections, so once things are connected successfully, it should look something like this:

     

    client 129: 'FLUID Synth (2143)' [type=user,pid=2143]

        0 'Synth input port (2143:0)'

        Connected From: 130:0

    client 130: 'Client-130' [type=user,pid=3127]

        0 'Virtual RawMIDI '

        Connecting To: 129:0

     

    Note also that connections made by aconnect are not persistent; Each time the VM or the synthesizer are relaunched, the connection must be re-established.  There's probably some way to make them connect automatically, but I haven't yet discovered it.

     

    Using MIDI output with VMware Fusion on a macOS host

    VMware Fusion will send MIDI messages to the macOS CoreMIDI service.  There is no built-in facility for directing the MIDI messages to a particular device.

     

    One option for rendering MIDI output into audible music is FluidSynth, which for example can be installed through HomeBrew:

    1. Run the command: brew install fluid-synth
    2. Fetch a SoundFont, e.g. from the page at https://github.com/urish/cinto/blob/master/media/FluidR3%20GM.sf2 , and put it in some shared location, e.g. /usr/local/share/fluidsynth would do nicely.
    3. Launch the synthesizer with the command: fluidsynth -o midi.autoconnect=1 /usr/local/share/fluidsynth/FluidR3\ GM.sf2

    The SB16's MIDI output should now be audible through the host's default audio output device.  Refer to the FluidSynth documentation for further detail.

     

    Configuring your guest to produce MIDI output

    Using MIDI output with MS-DOS guest games and programs

    Look for a SETUP.EXE or some other configuration program which can be used to select sound and music output.  If possible, choose General MIDI or MPU-401 or Roland MT-32 for the output device.  If an I/O port must be specified, use 330 –  typically that is the default anyway.  Using DOOM as an example, run SETUP.EXE, select Choose Music Sound Card, and choose General MIDI, and choose 330 as the MIDI port.

     

    Some programs will use command-line arguments to specify the sound system, such as specifying m for MPU-401 or r for Roland MT-32.  Using the LucasArts Day of the Tentacle demo as an example, run dottdemo r to launch the demo with MIDI music – versus dottdemo a to use Adlib/OPL3 music.

     

    For further information, refer to your program's command-line help or documentation.

     

    Using MIDI output with Microsoft Windows 95 as a guest OS

    With the Creative Labs Sound Blaster 16 or AWE-32 driver installed in the Windows 95 virtual machine, go into the guest's Control Panel > Multimedia, and go to the MIDI tab.  With Single Instrument selected, you should be able to choose between MIDI for External MIDI Port (which will use the Sound Blaster 16's MPU-401 interface and send MIDI to the host) and MIDI for Internal OPL2/OPL3 FM Synthesis (which will use the Sound Blaster 16's Adlib/OPL3 emulation to render MIDI into audio).

     

    Windows Media Player will use the MIDI settings in Control Panel when playing back MIDI files.  Try it out using the CANYON.MID and PASSPORT.MID files included with Windows.

     

    Acknowledgements

    These Sound Blaster 16 emulation improvements would not have been possible without the patient support of my sound-enthusiast colleagues, most notably Kamen – who helped with countless code reviews – and my manager Richard, who can finally play DOOM with sound and music.  Many others provided quiet encouragement and feedback to help along the way.