Description

The speaker-output is always enabled on the SB16; speaker enable/disable commands are simply ignored. Only the SB Pro and earlier models can toggle the speaker-output via speaker enable/disable commands.

This fixes the muted digital speech issue in "Monkey Island 2: LeChuck's Revenge Ultimate Talkie Edition" (speech works in all other DOSBox variants).

Proof

• DOSBox SVN just ignores speaker enable/disable commands for the SB16:
  https://github.com/joncampbell123/dosbox-svn/blob/master/src/hardware/sblaster.cpp#L240

• The DOSBox-X documentation mentions that the speaker enable/disable commands only work on SB Pro and earlier models and have no effect on the SB16 where the speaker is always enabled.

• The MIDIto r12 "Swiss Army Knife" MIDI & OPL tool has a special "DSP fix" option to emulate the speaker enable/disable commands for the SB16 and later models where they're not implemented:

  -dsp or /dsp will provide some fixes for SB16/32/AWE. Fixes at the moment include:
  * Fix Turn On/OFF Speaker commands by setting voice volume to zero when
    Turn OFF Speaker command is sent. Volume will be restored by Turn On Speaker
    command.
  

Manual testing

Tested "Monkey Island 2: LeChuck's Revenge Ultimate Talkie Edition" from eXoDOS v5 and digital speech works fine in the intro sequence.

Tested Gods with SBPro 2 and SB16; digital audio samples work fine in the intro music.

Tested a couple of MOD players with SBPro 2 and SB16.

@kcgen let me know if you think this change breaks the click & pop prevention in any way. I haven't specifically tested that because I think it should be fine.

Checklist

Please tick the items as you have addressed them. Don't remove items; leave the ones that are not applicable unchecked.

I have:

• followed the project's contributing guidelines and code of conduct.
• performed a self-review of my code.
• commented on the particularly hard-to-understand areas of my code.
• split my work into well-defined, bisectable commits, and I named my commits well.
• applied the appropriate labels (bug, enhancement, refactoring, documentation, etc.)
• checked that all my commits can be built.
• confirmed that my code does not cause performance regressions (e.g., by running the Quake benchmark).
• added unit tests where applicable to prove the correctness of my code and to avoid future regressions.
• made corresponding changes to the documentation or the website according to the documentation guidelines.
• locally verified my website or documentation changes.