Manual: Setup/Soundcard

Soundcard tab of the settings dialog

OpenMPT automatically detects installed sound devices on your computer, and in this page you can assign settings based on your computer's capabilities. If you are having trouble with playback, you may want to alter these settings so that OpenMPT uses less processing power for rendering audio. For more tips on fixing audio issues, check the troubleshooting section further below.

Soundcard Options

Sound Device

Shows the current audio device and driver that OpenMPT is using. Clicking on this field will open a list where you can choose another device. The new device is used as soon as you apply all changes in the dialog.

OpenMPT is currently phasing out support for some older sound APIs (MME / WaveOut) which may be removed in a future version. If you still want to use these, you can check the Show deprecated devices checkbox.

If a new audio device is plugged into the computer while OpenMPT is running, the Rescan button can be used to refresh this list.

OpenMPT defaults to using the shared mode WASAPI audio API, which provides a good compromise between low latency and compatibility and is the standard audio API in Windows. For low-latency and device-exclusive audio playback, WASAPI exclusive mode, as well as support for ASIO and WaveRT kernel streaming are also available.

Some ASIO drivers may not be able to play several audio streams at once (exclusive access). This may lead to some unwanted consequences described in the FAQ. One such driver is the popular ASIO4All driver. WaveRT is always exclusive.

It is recommended to use the default WASAPI shared mode. If you can afford having OpenMPT access your audio device exclusively (i.e. no other application may play any sound while OpenMPT is playing), it is recommended to use either ASIO (if available) or WASAPI exclusive mode, or WaveRT if very low latency is a major concern and ASIO is not available.

Setup Device

Brings up the system sound control panel (WASAPI devices) or the ASIO control panel (ASIO devices).

Latency

Here you can specify the suggested output latency of your sound device. Basically the Latency setting describes the timing difference between any kind of user input and the audio output, so generally this value should be as low as possible. Too small values can introduce unwanted audio artefacts such as clicks and drop-outs. A slow CPU or usage of plugins that require a lot of processing time may force you to pick a higher setting.

Some drivers may automatically pick a suitable latency setting regardless of the user’s choice (such as WASAPI in exclusive mode or certain ASIO drivers), or they will just pick a latency setting that is as close as possible to the settings suggested by the user.

Period

This setting sets the suggested period (or interval) the sound output buffer gets updated by OpenMPT. The smaller the period is, the better the chance that the sound buffer does not drain empty which would result in audible crackling. This setting currently also affects the accuracy (jitter) and speed of GUI updates, note inputting, MIDI recording and similar actions. Shorter periods slightly increase the CPU usage, but any computer should be able to handle an update interval of 5ms, so try starting from there when configuring this value.

As with the latency setting, this value is considered just a suggestion to the driver and the actual value used might deviate a bit from the selected value.

Since the number of audio buffers is fixed for ASIO drivers, the period option is not available with such drivers. In that case, the period is always half the latency.

In general, you do not have to care much about this setting, but it should be as low as possible for obvious reasons.

Direct Mode / Use Device Exclusively

Use Device Exclusively (WASAPI)

Opens the driver in exclusive mode, i.e. no other application is allowed to access the sound card while OpenMPT uses it. This bypasses the whole Windows audio mixing and buffering stack. It can thus be used to reduce latency.

Direct Mode (MME)

This setting demands the Windows audio stack to not perform any further conversion of the audio data (i.e. the number of channels, the sample rate and the sample format should not be changed and the device should be set exactly to the requested settings). Current Windows versions ignore this setting. It is useful on some Wine setups though when the Wine-internal sample conversion has poor performance and Wine should just forward the audio data as is to the underlying system backend.

Boost Thread Priority

If enabled, the audio rendering thread is given a higher processing priority, so that it is less likely to produce drop-outs. Disabling this setting might result in audible crackling even when your system gets only slightly busy.

Unless you experience problems, it is recommended to leave this setting enabled.

Hardware Timing

ASIO drivers can provide exact sound device output timestamps to OpenMPT. If you want OpenMPT to rely on those and not do its own timing measurements, enable this option. However, if the driver misbehaves and reports wrong timing information, this will cause severe problems with GUI updates, recording and VST plugins.

Output Format

Shows the sample rate in the first field, number of channels in the second and the bit depth in the third field and dithering in the last field. Clicking on either of these opens a list where you can choose another setting.

Sample Rate

OpenMPT defaults to 48000 Hz. However, some broken VST plugins expect 44100 Hz sampling rate and do not work correctly with any other rate. Windows systems and most audio devices however, by default, use 48000 Hz internally for all audio processing. If you are not using a WASAPI exclusive mode, ASIO, or WaveRT device, this results in all audio to be resampled to the Windows internal sampling rate anyway. Lowering the sample rate reduces CPU usage almost proportionally and may thus be an option for slower systems in order to reduce CPU usage. It is recommended to use 48000 Hz or, if you are using broken VST plugins, 44100 Hz.

Channels

The number of output channels OpenMPT will use. It is recommended to leave this at "stereo" unless you have 4 (or more) speakers attached and want to have quad surround output.

Bit Depth

For devices which OpenMPT accesses directly, this setting allows changing the output bit depth (and thus dynamic range) of the audio device. For devices which get routed to the system audio stack, OpenMPT will choose the best possible bit depth and not allow changing it. It is recommended to use either 24-Bit, 32-Bit, or Float 32-Bit for exclusively accessed devices. Since OpenMPT’s mixing code always works with 32-Bit precision, using a lower output bit depth does not gain performance.

Dithering

When reducing bit depth, dithering can be applied to the audio signal in order to transform harmonic distortion of quantization into a more uniform noise floor. It is recommended to leave this value at the default.

Channel Mapping

A lot of professional audio devices support more than 2 channels and have a lot of different output jacks. These are almost always presented as a single ASIO device to applications. With this setting, you can map each OpenMPT output channel to one specific channel of your ASIO device. Please note that some drivers only provide meaningful names for the output channels when the device is already running.

General Options

When Playback Is Stopped

• Close Driver: Normally, OpenMPT closes the audio device when the playback is stopped. Some ASIO drivers however take a very long time to open or close, in which case this results in undesirable delays.
• Pause Driver: OpenMPT will just pause the ASIO driver. Some ASIO drivers do not allow other applications to use the device in this state.
• Play Silence: Even more ASIO drivers will not allow other applications to use the device in this state. This setting also causes additional power consumption even when playback is stopped, which might be undesirable on mobile computers.

If you do not care about power consumption or about concurrent access to the audio device with other applications, it is recommended to select "play silence". Otherwise you have to trade power consumption and concurrent access versus potential delays when starting and stopping playback.

Open Device At Startup

Opens the audio device directly when OpenMPT starts. This moves a potential delay during audio device initialization from the first time you play a sound in OpenMPT to the time OpenMPT starts.

Statistics

At the bottom of this setup page, you can see the actual number of buffers, the period and the real latency used for playback. These values are shown as long as OpenMPT is outputting sound, otherwise the box will stay empty.

Troubleshoot

If you find that your track “stutters” during playback, you may be trying to process more audio than your computer can handle. To troubleshoot, try doing the following in this order.

• Try a WASAPI device without Use device exclusively.
• Use Period of 5ms or 10ms.
• Increase Latency in 5-10ms steps.
• When working with plugins, verify that you mostly use plugins that have the same “bitness” as the hosts (e.g. use 32-bit plugins when using OpenMPT 32-bit and 64-bit when using OpenMPT 64-bit). Every bridged plugin adds latency to the mixing process, hence there should be as few bridged plugins as possible.
• Reduce the Sample Rate one step at a time to a minimum of 44100 Hz. Anything less than this can create a vast difference between what you hear and what will be recorded when you export the file to audio.
• If you still encounter stuttering in playback and you are using plugins, you should try to reduce the number of plugins used in your song. If you use an instrument plugin that plays only a few notes or less, consider rendering the notes and importing these notes as samples (more info on rendering is found in the Saving and Exporting section). Sample playback requires much less processing power than instrument plugin processing. Also, many plugins have very high CPU usage and can soak up a large percentage of your processing power.