Sound blaster live linux driver

As an operating system, Linux has many things to recommend it over Windows. Gaming, alas, is not one of them. Compared to Windows, Linux just doesn't have anywhere near the same level of good games. Yes, there are a few here and there, but overall, Windows continues to dominate as the PC gaming platform of choice, with the widest array of content and the most up-to-date graphics and audio drivers.

Conventional wisdom dictates that it's always better to run games and applications natively. In the past, several game publishers would try to port their titles to Linux, but the return on investment was just too small. At one point, Loki tried to make a business out of porting titles from Windows to Linux, in much the way that MacPlay ported Windows games to the Apple platform. But Loki imploded in 2002, and no one else has tried such an ambitious approach.

The WineX project was started to enable Windows gaming on the Linux platform. Taking the WineX code and adding support and subscription options, TransGaming is trying to create a somewhat different business model. Instead of porting Windows titles to Linux, Windows games simply run under Linux.

TransGaming recently gave WineX a new name, Cedega, and announced support for a number of DirectX 9 titles. Thanks to the Cedega application, users have at least a chance at running some of their favorite Windows games on Linux -- the key word being chance. It all depends on a number of factors, one of which is, how much futzing are you prepared to do to make a Windows game run on Linux? If you're a seasoned Linux user, an afternoon spent twiddling .conf file can be fine entertainment. If you just want a "click-and-go" gaming experience, however, Cedega may not be for you.

We tried Cedega out on three different distributions (and with a bunch of games). The results were decidedly mixed.

We tested Cedega on there different distributions: Fedora Core 2, Suse 9.1 and Xandros OC (the free, downloadable version of Xandros 2.0). The purpose was to see if any one of these distributions fared much better than another to get games up and running.

We tried a pretty wide variety of games on the three systems, but from the outset, we decided that we weren't going to expend any heroic efforts to get a game up and running. If we hit into trouble, we spent a few minutes trying to troubleshoot, but if after about fifteen minutes we couldn't make a game work, we punted and moved on to the next game.

Fedora Core 2 Suse 9.1 Xandros OC

CPU AMD Athlon XP 1900 Pentium 4 3.0 GHz Pentium 4

System RAM 512MB 512MB PC3200 DDR 512MB

3D Card GeForce FX 5700 Nvidia GeForce FX 5700 Ultra GeForce FX 5700 Ultra and ATI Radeon 9800 XT

Sound Card Sound Blaster Live Sound Blaster Live Sound Blaster Live

We tried a combination of games that are both supported and unsupported officially by Cedega and we found that only a select few games would just come up and run without a hitch. For each of the distributions, we've noted what happened when we tried to install and play each of our test games.

We wanted to find out more about how Cedega actually makes Windows games run on Linux and TransGaming's Vikas Gupta and Gavriel State were kind enough to take us through some of Cedega's inner workings.

ET: How does Cedega take Win32 code and translate into something you can run on Linux?

Cedega does not use a virtual machine architecture. It actually loads and runs Win32 programs directly on the system.

There are essentially two main things that need to happen when running a Windows executable on Linux: The binary has to be loaded into memory on the Linux system and then dynamically linked to code that provides an implementation of the Win32 APIs that the program is using. The binary loader aspect is relatively straightforward but the real magic and complexity is in the implementation of the APIs.

The APIs that Windows games are mostly built on top of are primarily based on Microsoft's DirectX system. These APIs include facilities for handling 3D graphics (Direct3D), mouse and keyboard input (DirectInput), audio (DirectSound), and so on. TransGaming creates compatible versions of Windows APIs that work on top of Linux equivalents, such as the OpenGL and X11 graphic APIs and the OSS and ALSA audio APIs. Cedega 4.0 is the culmination of over four years of effort on these APIs.

ET: What are the key components in Cedega's architecture that make it work?

Cedega needs to implement the Win32 APIs that are involved in running all the software that comes on a typical game CD. That doesn't just mean the game code itself, but also components such as the installer and any copy protection code the game uses.

For the games themselves, the most important set of APIs are the various DirectX components: Direct3D, DirectSound, DirectInput, etc. But for the rest of it - the installers, updaters, etc - we've had to implement everything from network protocols to APIs as complex as DCOM. That was quite a big job, but it was absolutely required for us to be able to run games built with InstallShield installers, as InstallShield uses a client-server architecture which is based on DCOM.

One of the other key components of the architecture is the implementation of the kernel level primitives. In the architecture used in previous versions, processing of Windows kernel level objects took place in a separate process that ran alongside the application processes. Communication with this process was relatively slow, making any code that made heavy use of kernel level synchronization primitives perform poorly.

In Cedega 4.0, we've changed this architecture and effectively lifted the kernel level objects into a shared user space. Each process running under Cedega can essentially "become" the Win32 kernel temporarily. This provides a significant performance boost for some applications. We wrote up a Cedega white paper on Reducing WineServer Overhead via a Shared-Memory approach some time ago, when it was in an early prototype stage:

ET: Do you have a kind of D3D-to-OpenGL wrapper that takes D3D calls and converts them into OpenGL calls to do 3D rendering?

Internally, Cedega deals with 3D by implementing the D3D HAL architecture and providing a D3D driver underneath. This allows us to do several things. Firstly, it means that we can consolidate our driver code in a single place, rather then having separate implementations of each of the D3D API versions. It also allows us the flexibility to use the best choice of graphics back-end available on the target system.

On Linux and Mac OS X, we use a back-end driver that implements the D3D HAL calls on top of OpenGL. On other platforms, we have the flexibility to go directly to hardware if we like.

ET: Which sound server do you use and how do you translate Dsound/Dsound3D calls? Are you using OpenAL?

Again, we use a flexible back-end architecture here, so we have support for multiple back ends. These include both ALSA and OSS APIs on Linux and CoreAudio on Mac OS X. Depending on the flexibility of the underlying hardware and API we're using, we can send buffers directly to the hardware to be mixed, or we can do the mixing ourselves.

We've looked at OpenAL, but it lacks some of the functionality we would need to implement DirectSound, unfortunately. We've had some discussions with various people about adding OpenAL extensions that would allow us to do an OpenAL back end, but ultimately that wouldn't buy us that much, as we are already using the lower level APIs on our various target platforms.

ET: Did you have to reverse-engineer the Windows kernel(s) to make Cedega work?

Not at all. TransGaming never attempts to disassemble Microsoft's code, whether it's in the kernel, DirectX, or elsewhere. We obtain the majority of our information from publicly available sources such as online documentation, header files, as well as the occasional technical paper by a game developer. We also write test cases that we use to determine what the API behavior is supposed to be like when the documentation isn't specific enough. We use all of this information to craft the APIs and then we extensively test our versions of the APIs against various games.

We do use tracing tools that allow us to monitor exactly which APIs are called by a program and what parameters are passed. This is the primary tool we use when we see a divergence between expected and observed behavior. It does leave us scratching our heads in some cases though, because we can only guess at the underlying logic being used by the program. Nonetheless, our knowledge and expertise with the APIs is so extensive that we've become quite proficient at tracking down issues and getting support enabled very quickly. TransGaming's knowledge of DirectX is probably second only to Microsoft's own.

ET: How about PS 1.4 and PS 2.0. When will they be supported?