Microsoft DirectX 8.1 (Visual Basic) |
By using the DSBCAPS_LOCDEFER flag when creating a buffer, you can defer the allocation of buffers to hardware-mixed or software-mixed memory until the moment when they are played. For information, see Dynamic Voice Management.
The effect of deferred allocation on application performance depends on the type of DirectSound accelerator in the user's system.
Consider the case of a PCI accelerator. When a deferred buffer is played, DirectSound first determines if there is hardware available to play the sound. Assuming there is, DirectSound then ensures that the hardware has access to the sound data, which remains where it is. Finally, DirectSound tells the hardware to start playing. This process is both efficient and fast.
Note The DirectSound voice manager allocates hardware mixing resources, not memory. On a PCI card, the buffer occupies the same memory before and after it is allocated, regardless of whether it is allocated to the hardware mixer or the software mixer.
If the user has an ISA-based accelerator, the situation is quite different. In this case, the act of getting audio data to a hardware-mixed buffer is very slow, because the data needs to cross the ISA bus and be loaded into memory on the sound card before it can be mixed. For deferred buffers, this can introduce an unacceptable delay between when the play call is made and when the sound starts. For this reason, using voice management is not recommended on ISA-based DirectSound accelerator cards.
It is easy to prevent your application from using voice management on ISA devices. A buffer won't be assigned to a on-card memory unless the DSBCAPS_STATIC flag is set. Therefore, as long as you do not combine DSBCAPS_STATIC and DSBCAPS_LOCDEFER, there is no danger that buffers will be assigned to on-card memory at play time.
Using DSBCAPS_STATIC by itself ensures that the buffer will take advantage of any existing memory on an ISA card, but has no effect on a PCI card, where in the absence of other flags, DirectSound will attempt to place the buffer under hardware control but still in system memory. Using DSBCAPS_LOCDEFER by itself has no effect on an ISA card, since the buffer is always placed in system memory and is not managed by the hardware.
The following table summarizes the effects of the DSBCAPS_STATIC and DSBCAPS_LOCDEFER flags on buffers created for ISA and PCI devices.
Card | Flags | Memory | HW acceleration |
ISA | DSBCAPS_STATIC | Hardware if available. | Yes, if in hardware memory. |
PCI | DSBCAPS_STATIC | System. | Yes, if hardware voice available; flag has no effect. |
ISA | DSBCAPS_LOCDEFER | Hardware if available, if DSBCAPS_STATIC set. | Yes, if in hardware memory; but latency on first play. |
PCI | DSBCAPS_LOCDEFER | System. | Yes, if hardware voice available. |
To take advantage of acceleration on ISA cards without running into the dangers presented by deferred allocation, first check the capabilities of the device. If the card reports more than zero static buffers and no streaming buffers, it is probably an older ISA card with on-card memory. You can then use the DSBCAPS_STATIC flag, but do not use DSBCAPS_LOCDEFER. If the card reports more than zero streaming buffers, it is probably a newer PCI-based accelerator card. In this case, you'll want to use DSBCAPS_LOCDEFER, and not DSBCAPS_STATIC, to make maximum use of the hardware voices.