Manual: Setup/Soundcard



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.

Sound Device
Shows the current audio device and driver that OpenMPT is using. If a new audio device is plugged into the computer while OpenMPT is running, the Rescan button can be used to refresh this list. 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.

For low-latency and exclusive audio playback, Kernel Streaming can be used on Windows XP (“WDM-KS”), WaveRT is available on Vista and later. It is recommended to use a low-latency WDM-KS, WaveRT or ASIO driver if 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. WDM-KS and WaveRT are always exclusive.

If ASIO is not available, or if you do not want OpenMPT to use the audio hardware exclusively, it is recommended to use WASAPI on Windows Vista and later (and Wine 1.8 and later). Note that the ASIO4All driver uses WDM-KS or WaveRT internally, so there is no real advantage in using it compared to using WDM-KS or WaveRT directly.

If none of the aforementioned drivers are available or if you experience problems with sound output due to mis-behaving drivers or a slow system, use a Wave Out device in OpenMPT. This is the most compatible way that OpenMPT can use to output audio.

Setup Device
Brings up the ASIO control panel (ASIO devices) or the system sound control panel (WASAPI 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 certain ASIO drivers or WASAPI in exclusive mode), 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 increase the CPU usage, but any decent computer should be able to handle an update interval of 5ms or less, 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 (WaveOut)
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). As this avoids the need to modify the audio data by the Windows audio stack, this setting can improve the latency. On Windows XP, Direct Mode may also improve overall performance on slower, older systems. It is also especially useful on some Wine setups when the Wine-internal sample conversion has poor performance and Wine should just forward the audio data as is to the underlying system backend. Modern Windows versions (Vista and later) might not honor this setting.

Use Device Exclusively (WASAPI on Windows Vista and later)
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 improve latency.

Use Primary Buffers (DirectSound on Windows XP)
Directly talks to the primary output buffer of the underlying hardware device. This bypasses the whole Windows audio mixing and buffering stack. It can thus be used to improve latency.

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 currently defaults to 44100 Hz because some broken VST plugins expect this sampling rate and do not work correctly with any other rate. Modern Windows systems (since Windows Vista) and most audio devices however, by default, use 48000 Hz internally for all audio processing. If you are not using an ASIO, WaveRT, WDM-KS or WASAPI exclusive mode 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 either 44100 Hz (if you are using broken VST plugins) or 48000 Hz (otherwise).

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
It is not recommended to set the bit depth to anything less than 16-Bit. In fact, you should use 32-Bit bit depth or floating point if possible for best audio quality and the greatest dynamic range. Since OpenMPT’s mixing always code 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 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.

When Playback Is Stopped

 * Close Driver: Normally, OpenMPT closes the audio device when the playback is stopped. Some ASIO drivers however take 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.
 * First off, try disabling player effects if any of them are enabled.
 * 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.
 * When working with lots of sample channels, reduce the polyphony setting in the Mixer settings as much as you can. For a solo piano piece, you can probably reduce this to 16 with no tonal loss.
 * Reduce the Mixing Quality one step at a time to a minimum of 22050 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.

de:Handbuch: Setup/Soundcard