The output device buffer length.

    DWORD length


lengthThe buffer length in milliseconds.


The device buffer is where the final mix of all playing channels is placed, ready for the device to play. Its length affects the latency of things like starting and stopping playback of a channel, so you will probably want to avoid setting it unnecessarily high, but setting it too short could result in breaks in the sound. When using a large device buffer, the BASS_ATTRIB_BUFFER attribute could be used to skip the channel buffering step, to avoid further increasing latency for real-time generated sound and/or DSP/FX changes.

The buffer length needs to be a multiple of, and at least double, the device's update period, which can be set via the BASS_CONFIG_DEV_PERIOD option. The buffer length will rounded up automatically if necessary to achieve that. The system may also choose to use a different buffer length if the requested one is too short or long, or needs rounding for granularity.

Changes to this config setting only affect subsequently initialized devices, not any that are already initialized. The "No Sound" device does not have a buffer, so is unaffected by this option.


On Windows, this config option only applies when WASAPI output is used.

This option is not available on OSX or iOS. The device buffer length on those platforms is twice the device update period, which can be set via the BASS_CONFIG_DEV_PERIOD option.

On Linux, BASS will attempt to set the device buffer-feeding thread to real-time priority (as on other platforms) to reduce the chances of it getting starved of CPU, but if that is not possible (eg. the user account lacks permission) then it may be necessary to increase the buffer length to avoid breaks in the output when the CPU is busy.

When using AudioTrack output on Android, the buffer length will be automatically raised to the minimum given by the AudioTrack.getMinBufferSize method if necessary.

See also