Running Sound Applications under Wine
Open any of the popular music trade magazines such as Keyboard or Sound On Sound, and you can't miss the plethora of colorful advertisements for sound and music software, all of it for Windows and Mac. Much of this software is of truly outstanding quality; some of it has set industry standards for features and performance, and not a bit of it is available for any platform other than Windows and Mac.
The open-source audio development community has made great strides toward providing musicians with a freely available alternative to the Win/Mac hegemony, and they deserve great praise. Nevertheless, it also must be admitted that our community is still relatively small. Potential converts to Linux often ask whether they can run their familiar programs successfully under Linux, and that criterion alone can determine whether they make the change to Linux. For all of Linux's vaunted technical superiority, it's a no-show if you need an application that simply doesn't exist for it.
This article describes how to set up and use the Wine Windows emulation environment for sound and music applications. I test a few programs, and I indicate the quality of performance you can reasonably expect from running Windows music and sound software under Wine.
System emulators come in two basic flavors, machine architecture emulators and operating system emulators. Wine is a complete package that emulates the Windows operating system. Windows itself is not required. Wine includes its own versions of the Windows system DLLs, but you can use the native Windows versions if you prefer. Depending on the intended use, the system may require other native support software expected by your applications.
Wine's sound capabilities have developed largely in response to users who want to play their favorite games without leaving their favorite operating system. As a result, Wine has become a good candidate for running Windows audio and MIDI applications. However, before installing the emulator, you should check its documentation for the most current sound system status reports. If you intend to run a particular sound or MIDI application under emulation, your success will depend on a variety of factors, including support for the original file formats, audio sampling rates and required drivers.
The tests in this article were performed on an 800MHz machine with an M-Audio Delta 66 digital audio I/O system and an SBLive Value sound card. The software base included ALSA 1.0.4, JACK 0.99 and a rock-solid 2.4.26 Linux kernel patched for low latency. As always, your mileage may vary.
Wine is an acronym for either WINdows Emulator or Wine Is Not an Emulator. Curiously, both interpretations are correct. Wine is the wine executable, a Linux program that runs Windows programs, and it is equally libwine, a library designed to assist Windows/Linux cross-platform development.
After 12 years at the alpha-release level, Wine is now officially a beta-stage project. Hopefully, this event signals a more consistently stable environment, but some programs still may behave erratically. The Wine documentation gives detailed instructions for submitting useful bug reports, so if you find that your favorite Windows program doesn't work well (or at all) under Wine, you can help yourself and the project by submitting a report.
Wine's support for basic sound and MIDI is good, and support for audio extensions such as Microsoft's DirectX is improving, but you won't be able to use Wine to run large, integrated multimedia applications, such as Cubase or SONAR. However, Wine can run a variety of sound and music programs, even some fairly big packages. Check the Wine Web site (see the on-line Resources) for links to lists that rate the compatibility of various Windows applications.
The WineHQ Web site provides Wine in a variety of package formats, including the common RPM and DEB formats and full source tarball. Use your package manager of choice to install the latest version. If you decide to build Wine from the source package, simply open an xterm, enter your new wine-x.x.x directory and run ./tools/wineinstall (as a normal user). Answer the prompts, then relax and let the Wine installer do its stuff.
After installation, run the notepad.exe file included with the distribution:
wine $HOME/c/windows/notepad.exe
If the familiar editor appears, Wine is ready for use. Now you can try to run some Windows music and sound applications.
System requirements and build procedures may change from version to version, so if you decide to build Wine yourself, be sure to read the README and follow the recommended installation instructions included with the package. The version used in this article is Wine 0.9.6, released on January 20, 2006.
Similis sum folio de quo ludunt venti.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- A Topic for Discussion - Open Source Feature-Richness?
- New Products
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- The Secret Password Is...
- myip
3 hours 33 min ago - Keeping track of IP address
5 hours 24 min ago - Roll your own dynamic dns
10 hours 37 min ago - Please correct the URL for Salt Stack's web site
13 hours 49 min ago - Android is Linux -- why no better inter-operation
16 hours 4 min ago - Connecting Android device to desktop Linux via USB
16 hours 33 min ago - Find new cell phone and tablet pc
17 hours 31 min ago - Epistle
19 hours 9 sec ago - Automatically updating Guest Additions
20 hours 8 min ago - I like your topic on android
20 hours 55 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




Comments
Great article for Apple users
I am a long-year apple-fan. I dont use it for professional use in music-business, but the band-in-a-box program is a great piece of work, done by apple. So especially this part of the article was interesting for me. :-)
I have huge problems with
I have huge problems with wine first you can't run two sound programs at once. I can't say output an MP3 with one wine program and try to record it at same time from Linux by listening to the sound card output. Also the worse problem is I have a program that outputs MP3s and I can't play them in LINUX because it says the file is EXECUTABLE type wine. If I setup this same program on Windows box, it would output MP3s. I can take those MP3s to my Linux box and do whatever I wanted. Now with wine it doesn't work. Wine must put some binary output in the file itself saying it is an executable file hence unusable MP3 in Linux.
Good article - bad premise
It wonderful to see that this kind of work is being done, but without official support from the vendors of the packages in question, one os SOL if there are any problems that the community cant solve.
Its simply easier t run these natively.
*easier* hmm.. lot's of
*easier*
hmm.. lot's of great cliches come to mind, great things, patience, nothing good comes, something or other.
you are right, though. i just want to run things out of pride for my OS. i don't actually want any of these proprietary beasts; i just want to be all like, "say I can't run Reaktor in Ubuntu, go ahead." Muuuhaaahaaa
"make my day." it's really going to be great when people are lagging along on Vista with insane resources and I speed by in some light-weight little linux rig with a P4.
Sorry to be a 'fanboi' as I have only recently learned the word. I always said that I was a partisan.
worth doing sometimes - not always
Oldman has a valid point, although there are still times when running windows sound apps under Linux is worth it.
For everyday computing, such as web browsing, mail, viewing movies etc. I use Linux. This is because Windows committed suicide on me several times, forcing me to reinstall it, and all my applications, each time. If I want to take a break and dabble in some music making I don't want to reboot into Windows. Audiomulch works under wine without any hastle and I have never known it to crash. One should also remember that Microsoft is making it increasingly hard to update unlicensed copies of its current operating systems. If you want an MS OS and you don't want to pay for it, then sooner or later you will probably have to restrict yourself to software that will run on Windows 2000.
One thing Dave Phillips didn't mention is that a great many VST plugins work under Linux, but outside the wine environment proper, using various wrappers such as dssi-vst. Most of the ones I have tried have also worked within audiomulch.
If you are setting up a dedicated studio and your tool of choice is cubase, ableton or whatever, and you don't want a lot of hastle, then of course you should choose an OS that won't give you any nonsense. As Dave said, at the moment those kind of tools don't work at all within Wine, and even when they begin to, there will probably be some pain involved. Then again, even though it will be harder work to get these to run flawlessly on Linux--Audiomulch's developer has a much friendlier attitude to Linux than the companies that make the other stuff--I suspect that this will indeed happen sooner or later.
That said, if you want to use ableton or whatever then you should do it on a mac rather than windows both because the audio latency is usually lower and because of all the other problems you get with windows that most windows users already know too well.
If, on the other hand, you are willing to do the nerd work, you may find it very useful to use windows audio apps alongside traditionally unix ones (of which there is a very long tradition) in a Linux environment. One reason is that it is possible to achieve very low, glitch-free, audio latency, even under very heavy system load. There is also a huge potential for working over a network in ways that tend not to happen under windows or mac os. Some of these, such as clustering, don't apply directly to windows apps and plugins running in wine or a VST wrapper, but others, such as syncing low latency audio backwards and forwards across a network, certainly do.
Amongst all of the flaming
Amongst all of the flaming going around on the subject of linux audio, you have just so happened to put my thoughts into words, when I'm giving other people advice.
Personally, linux and I are recently married and enjoying a long honeymoon after having a high school fling years ago. Cheating on my operating system is not negotiable. Whatever the limitations, I plan to go without a few impressive high-level audio manipulation GUIs and stick with my linux box through thick and thin.