Forward-oss Kernel Module
From Freespire
Introduction
The forward oss module works by creating a series of system calls for the oss devices that will forward the relevant data to a user space daemon that will then reformat the calls as alsa calls thereby creating the desired effect via the alsa sound drivers.
The Open Sound System works via the traditional Unix system call interface which is wrapped into the C library. ALSA, on the other hand, has a user space library that sits in between the application and the C library. The fact that this library is in between the application and the system makes ALSA easily extendible. ALSA, via libasound, is able to implement a plugin architecture. This is the primary reason that we prefer ALSA. The most important of the current plugins is a mixer plugin named dmix. This plugin implements software mixing for sound cards that do not implement hardware level mixing. As the extraordinarily popular Intel AC97 and High Definition Audio chips are examples of sound cards that do not, for the most part provide, hardware level mixing on Linux software level mixing is important to provide.
As OSS has no user space library to provide software mixing the mixing would have to be provided within the kernel. This would not only be a more difficult place to provide this feature, but it would also be bad policy to provide it there.
Before we further explain our methodology for converting OSS calls to ALSA calls it is helpful to look at how the other systems work.
Contents |
Kernel Space OSS Emulation
This is the simplest of the implementations. In this method the kernel side of the ALSA implementation implements the system calls for /dev/dsp and /dev/mixer.
Advantages
- As this is the simplest method it takes the least amount of work to get the job done.
- This method always works as long as there is only one program using the sound card.
- Most after market sound cards implement hardware mixing which makes it possible to use
this method with more than one program.
Disadvantages
- It is not feasible to implement software mixing in an elegant manner with this method.
- With most integrated audio chipsets it is only possible to play one sound this way.
- When using the OSS emulation the rest of ALSA is blocked from using the sound device.
- If a program opens /dev/dsp and does not close it when it is done using it then the
sound device is effectively blocked until that program closes.
User Space LD_PRELOAD Emulation
In this implementation there is a library that is inserted in between the OSS application and the C library. This done via the preload feature of the runtime linker. This library reimplements the C library input/output functions so that they check to see if the current call is going to act on the sound device. If the call is to the sound device it reformats the call to match the corresponding libasound function call. If the function call does not operate on the sound device then the call is passed on to the C library.
Advantages
- With this method the system can provide software mixing.
- For most system calls the overhead added to this is minimal.
Disadvantages
- It is not always possible to insert the library between the application and the C library.
- If the OSS application makes heavy use of the poll family of system call this can create quite a bit of overhead.
- You have to reimplement all of the C library functions that can make a system call. This adds quite a bit to the amount of code to maintain. open example
- You have to either call all OSS applications with a wrapper script, which is hard to maintain, or you have to set the LD_PRELOAD environment variable globally which creates a lot of overhead.
Forward OSS System
With the forward OSS system the system calls for the sound device are reimplemented directly in the kernel. All of the calls made by the OSS application enter the kernel. The kernel then wakes up a user space daemon that reads the data out of /dev/forward. This daemon then reformats the function calls to be made by libasound.
Advantages
- This technique works with all applications.
- It provides software mixing.
- It does not create overhead on system calls not made to the sound device.
Disadvantages
- This technique creates the most overhead of them all in calls made to the sound device. This adds to the latency in the audio stream (The added overhead and latency seems to be well within acceptable parameters.)
