In Windows Vista, Microsoft rewrote most of their audio systems. There are a number of audio APIs in the Windows API, notably winmm.dll, dsound.dll, and mmdevapi.dll. WinMM and DSound can be considered "legacy" APIs. For Windows Vista, Microsoft rewrote the legacy APIs to route their audio through the main audio system called MMDevAPI. More information can be found on MSDN's User-Mode Audio Components page.
Wine-1.3.25-1.3.30 has undergone the same rewrite. All of Wine's audio APIs are now based on the new MMDevAPI implementations, and are currently undergoing bug fixing to clean up the remaining issues caused by the rewrite.
Wine's audio systems require a lot from your system's audio libraries. It relies on your system to perform mixing of separate audio streams, as well as to provide resampling. On modern ALSA machines, the "default" device can typically do both. However, if you configure Wine or another application to use your audio hardware directly (the "hw:0" interface, for example), you may find that only a single audio stream will play, which can cause audio problems in many applications. Please be sure to use only interfaces which support multiple streams.
Ever missed the 'Ding' system sound and other standard Windows audio cues? Wine can play them if you tell it where to find PCM .wav files. Because every UNIX is different, Wine can't guess where to find them. See bug 21277 and add a section like this to your drive_c/windows/win.ini
[Sounds] Default=/usr/share/sounds/question.wav SystemExclamation=/usr/share/sounds/error.wav
Of course you must substitute paths to .wav PCM files found on your disk. Either UNIX or DOS pathname syntax is acceptable.
Help! My sound isn't working!
Here is some information about how to debug sound issues, or give the developers enough information to help you.
Make sure that Wine chose the correct driver backend. As of Wine 1.3.28, Wine should select the correct backend for you. If you don't know which backend is correct, this is probably not your problem. To see which backend Wine chose, launch the Wine configuration program (winecfg) and click the Audio tab. If you are using a Wine prefix from an older version of Wine, you may have an incompatible driver hard-coded into the registry. Please delete the Audio entry inside of the [HKEY_CURRENT_USER\Software\Wine\Drivers] registry key with the "regedit" program. If none of the above apply and Wine is failing to select the correct backend, then you have encountered a bug in Wine's automatic driver selection and you should report it.
If Wine is using the correct backend and audio still does not work, please consider filing a bug. See below for a list of information to include when filing a bug.
One thing you can try is switching Wine's compatibility mode between Windows 7 and Windows XP. Recent applications will detect the Windows version and either use the legacy APIs for pre-Vista operating systems, or the new MMDevAPI module for post-Vista operating systems. Choosing either Windows 7 or Windows XP may cause your application to use a different audio system, which may have better success. Please consider filing a bug if you find that your application's audio works in one mode but not the other, as Wine should support both.
The Windows SDL library contains support for several audio backends, such as "winmm" and "dsound". If the SDL_AUDIODRIVER environment variable is set, then SDL loads the matching backend, or fails if the backend isn't available.
Since SDL is a cross-platform library, it has this same functionality on Linux. Accordingly, some Linux distributions' SDL package will set the SDL_AUDIODRIVER environment variable to match the Linux backend, so that SDL-using Linux applications will use the appropriate backend (e.g. "pulse").
But this creates problems for SDL applications run in Wine. The Windows SDL library loads the Linux SDL_AUDIODRIVER environment variable, which contains "pulse" or some other invalid backend for the Windows SDL library, and so audio fails to initialize in SDL-using Windows applications run through Wine.
The solution here is to unset your SDL_AUDIODRIVER environment variable before running Wine. This should restore your audio, as SDL will fall back on one of its default Windows drivers. Alternatively, you can create a new registry entry which will override the SDL_AUDIODRIVER environment variable for your Wine prefix:
[HKLM\System\CurrentControlSet\Control\Session Manager\Environment] SDL_AUDIODRIVER=""
There is a patch available here which adds this environment variable override automatically. Packagers may find it useful.
Wine's directmusic implementation (dmusic, dmime, dmloader, etc) is very incomplete. If your application uses directmusic, it will probably not play audio. This includes most games made with GameMaker. However, installing both "directmusic" and "dsound" using winetricks should give you working audio.
What to include when filing a bug
In addition to the usual bug guidelines, please also include all of the following information:
- Audio driver being used
- Operating system
If possible, a +tid,+mmdevapi,+winmm,+driver,+midi,+dsound,+dsound3d,+dmusic,+mci,+oss,+alsa,+coreaudio log. These can get very large very quickly, so try to do enough to trigger the bug, but no more.
(The dmusic modules have a whole boatload of channels: +dmime,+dmloader,+dmfile,+dmfileraw,+dmdump,+dmband,+dmusic,+dmcompos,+dmscript,+dmstyle,+dmsynth,+dmusic32,+dswave. You probably don't want these unless you know the application uses dmusic.)
Wine does its best to probe your system for information about the available devices, but ALSA's device enumeration does not work very well. Wine will detect your hardware devices, but it may not be able to find software devices you have configured. To tell Wine about these devices, please set the following registry keys:
HKCU\Software\Wine\Drivers\winealsa.drv\ALSAOutputDevices #Multi-string value containing output interface names HKCU\Software\Wine\Drivers\winealsa.drv\ALSAInputDevices #Multi-string value containing input interface names
You can specify them as defaults in the Audio tab in winecfg.
What about PulseAudio?
PulseAudio is a sound server that is included by default in many recent Linux distributions, and is required by the latest versions of the Gnome desktop. Wine has never had a PulseAudio driver. PulseAudio includes an ALSA compatibility layer that lets ALSA clients, such as Wine's ALSA driver, work with PulseAudio. In this manner, PulseAudio users should be supported by Wine. However, PulseAudio's ALSA compatibility is not perfect. There is a bug in the latest release of the ALSA compatibility plugin that can cause audio to stop working after a short period of running a program in Wine. A workaround is also present in Wine 1.3.26 and later. See Ubuntu bug 805940.
Some users have suggested disabling or removing PulseAudio as a workaround for Wine-related sound issues. This may fix your Wine-related sound issues, but it is not recommended as other software installed by your operating system may expect PulseAudio to be present. Wine's audio should work with PulseAudio through the ALSA driver. If audio does not work with PulseAudio, it is either a bug in Wine or in PulseAudio or its ALSA plugin.
Older (<1.0) PulseAudio
Users of older PulseAudio versions often run into a bug in the ALSA compatibility layer where audio will cut out after a period of time ranging from a few seconds to a half hour. This bug is fixed in PulseAudio >= 1.0 and alsa-plugins >= 1.0.25 (called "libasound2-plugins" on Ubuntu). But for users on operating systems that haven't released updated packages yet, a workaround is needed.
We can avoid using PulseAudio by using the program "pasuspender". This tells PulseAudio to release its hold on the audio hardware for the duration of a program's execution. This is a two step process.
First, tell Wine not to use the "default" audio device, which is routed through pulse, but instead to use your hardware directly. Set both of the "Output Device" dropdowns in winecfg to be your hardware device. Press OK to make the changes take effect.
Next, always run Wine with pasuspender. For example:
$ pasuspender -- /path/to/wine winecfg or $ pasuspender -- /path/to/wine 'C:\Program Files\My Favorite Application\Application.exe'
Now try your audio applications. Note that other audio-using applications may not work while Wine is running. The system should become normal again after Wine exits.
The best solution to this problem is to upgrade your PulseAudio and alsa-plugins packages.
What about JACK?
JACK, the low-latency sound server, had a driver in the old driver architecture. It has been removed as part of the transition to MMDevAPI. This means that there is no JACK support in Wine at this time. If a developer is sufficiently motivated, they could implement an audio driver to restore support for JACK. The new driver would be expected to pass all tests, especially those in <dlls/mmdevapi/tests>, <dlls/winmm/tests>, and <dlls/dsound/tests>. Additionally, Wine is currently not accepting new drivers until the audio situation settles down a little bit. An external git tree, frequently synced with main Wine, would be your best bet. If this is a project you think you might undertake, please contact the wine-devel mailing list before you begin.
Users wanting to create a "bridge" to forward Wine's ALSA output to JACK can find streamlined setup instructions here.
WineASIO users need not fear! WineASIO's implementation is completely separate from the old drivers. If your application does all of its audio IO through ASIO, then your audio experience should not change.