-
Notifications
You must be signed in to change notification settings - Fork 2
Hardware:Sound Blaster:Nagging the DSP
Apparently the Sound Blaster hardware allows software to send a Play
DMA block'' command (0x14) and then later send another Play DMA
block'' command without letting the previous one finish. Without missing
a sample the DSP resets its counter and continues playback. If the DSP
is always interrupted in this manner, audio can play forever without
finishing the block. Nagging the DSP this way has no effect on the
stream coming from the DMA controller, so to the end user, there are no
glitches or dropouts during playback.
A possible benefit of this technique is that the DSP never fires an IRQ because it never finishes the block. So a program using this technique never has to worry about handling and autodetecting the Sound Blaster IRQ.
This technique may cause problems with virtualization or emulation that assumes the program will let the previous one finish before sending another. It may cause audio to skip forward or play fast. This is an unusual use of the DSP that emulation is likely not designed to handle.
The technique can be used without problems if programming the card like a Sound Blaster or Sound Blaster Pro. Sound Blaster 16 (DSP 4.xx) commands however are less tolerant of nagging and using them this way can cause the DSP to miss/skip bytes or stop playing entirely.
| Format | Result (Sound Blaster 16 ViBRA) |
|---|---|
8-bit mono |
No problems |
8-bit stereo |
Depending on when the command is sent, the DSP may skip a byte then resume stereo playback from the odd byte. When it happens the user hears the left and right channels swap. |
16-bit mono |
If the command is sent at the right time, the DSP will stop playback entirely |
16-bit stereo |
If the command is sent at the right time, the DSP will stop playback entirely |