| | Open Sound System |
| Do you have problems with sound/audio application development? Don't panic! Click here for help! |
Information in this section is intended to programmers designing new device drivers to be included in OSS. There is nothing usefull for application programmers (programmers writing user land applications that use OSS).
Writing low level device drivers for Open Sound System (OSS) differs significantly from usual device driver programming because OSS is truly multi platform sound subsystem. A properly written OSS driver will work without any modifications under every operating system supported by OSS. At this moment OSS 4.0 is available for Linux, Solaris, FreeBSD, UnixWare and OpenServer. More ports will be introduced in the near future.
Traditionally device drivers have been written for a given operating system and it's not portable to any other operating system without more or less significant changes. This portability is possible because OSS contains a thin kernel abstraction layer which provides generic operating system for the low level drivers (that actually drive the hardware) and various upper layer modules (audio, mixer and MIDI cores).
To guarantee portability OSS drivers cannot call any kernel services directly. In fact they are not permitted to include any kernel header files. The driver includes just it's (automatically generated) private config file (driver_cfg.h) that includes the other header files required to compile the driver.
Device drivers differ from ordinary (user space) application code in many ways. For example there is no memory protection that prevens buggy driver from destroying the whole operating system (which in turn may trash the hard disks and file systems and cause permanent loss of all data stored in the computer. For this reason you should be very familiar in operating systems and kernel space programming in general. However you should also be able to make difference between operating system dependent details (which are completely uninteresting to OSS programmers) and the general kernel/driver programming concepts. Unfortunately most kernel and device driver programming books/courses cover just a given operating system. This may make getting good knowledge somehow difficult. For this reason it's recommended to study at least two operating systems before starting to write an OSS driver.
This guide is not intended to be a self contained kernel space programming cource. Important kernel concepts will be discussed just very briefly. The focus is on writing drivers for OSS.
In addition to kernel programming concepts you should be very familiar with OSS application programminmg. Whatever the driver does is some kind of mirror image of what the application does (and sees).
Finally you should know the hardware you are working on and understand how to map it's features to the OSS API. The primary design goal of the whole OSS subsystem is to provide perfect hardware abstraction. For this reason driver designers must avoid exposing features of the device in a way that makes it necessary to tailor applications for specific devices.
OSS is released under dual proprietary and Open Source license (GPLv2). Third party drivers will have to be released under this license scheme (GPLv2). The primary goal of whole Open Sound System (OSS) project is to keep OSS consistent. For this reason is recommended that all 3rd party drivers follow this licensing scheme. It is possible to develop "closed source" only drivers but in such cases the licensing details must be discussed with 4Front Technologies (sales@opensound.com).
Traditionally all OSS drivers have been written in ANSI C. However it's possible to implement drivers in C++ too (at this moment limited to Linux and Solaris only). There are several issues in writing C++ drivers and doing so sill require use of applied black magic (constructors/destructors and some built in library routines will need to be implemented in the driver). For this reason C++ should only be used when porting drivers that have already been written in C++ for some non-OSS operating system (say Windows or MacOS).
The recommended programming style is traditional Linux/Unix (no Windows oriented lpSomething variable names). Code indentation is the default indentation produced by GNU indent).
Open Sound System is truly hardware and operating system independent audio/sound subsystem. It supports audio, mixer (control panel) and MIDI devices. Some of the devices are real (physical hardware) devices while it's also possible to create virtual drivers that "emulate" a real device. Finally some devices may integrated on the motherboard, installed in some internal connector (say PCI) or connected to some external bus such as USB. For this reason the device driver for some device may be very different from drivers for some other type of device. However devices are often similar to some other device so it may be possible to use some existing driver as a skeleton for the new driver.
Most sound devices (sound cards) are multifunction combo devices that have audio, mixer and/or MIDI subdevices. It is also possible that the device has just one kind of functionality such as audio or MIDI. However mixer devices are rarely seen alone (without audio).
Audio is the most common functionality. Audio devices are used to play and/or record linear (PCM) or compressed (MP2/3, AC3, DTS, etc) audio streams.
Most audio devices (but not necessaily all) have some kind of volume control capability or other kind of device settings. OSS drivers provide access to such functionality by creating a mixer/control panel device file (or sometimes several of them). This mixer device file interface is the only recommended way to expose device dependent details to the applications and end users.
MIDI devices are ports used to transmit and receive MIDI data between a MIDI compatible device and application. Usually MIDI devices are communication ports similar to serial (RS323) devices. However it's also possible to create drivers for many kind of synthesizer chips by parsing MIDI stream sent by the application inside the driver.
Typically OSS device drivers have some kind of hardware which they control. However it's also possible to create virtual drivers whic for example take MIDI output from the application, translate it to audio and feed the result to some other device (by calling it's driver).
Most common type of sound cards are PCI devices. They may be add-on cards installed in a PCI (or PCI express) slot. Most motherboards have a built-in sound chip that is identical to PCI device from driver writer's point of view.
Legacy ISA devices are somehow similar to PCI but at this moment OSS doesn't have any framework for ISA devices. In theory it might be possible to create a driver for self identifying (PnP) ISA devices by faking a PCI driver but this doesn't necessaily work properly. Since ISA is a bus technology that disappeared about 10 years ago if's very unlikely that OSS will ever support it (again).
USB based devices are supported by OSS under Linux and Solaris (at this moment). However the USB framework is very monolithic at this moment. For this reason it's very difficult to create 3rd party USB sound drivers. It is possible but it will require tight co-operation with 4Front Technologies. Writing USB drivers for OSS is beyond the scope of this guide.
FireWire rather is similar to USB but at this moment there is no FireWire framework included in OSS. The same is true for Ethernet based audio devices. However it is possible to write user space drivers for these architectures by using the loopback audio (and/or MIDI) driver that is included in OSS.
Most sound devices are (PCI or USB) add-on devices and it's possible to have several of them installed in the same system. For this reason OSS drivers typically support several instances and the OSS driver framework is based on this model. Drivers should be developed to support as many instances as it's technically possible to have in a single system. For example with PCI devices the number of instances is limited by the number of PCI slots in the system (up to 5 in older machines and something like 1 or 2 in the latest motherboards which have PCI-X slots). However motherboards have typically just one sound chip and drivers for them don't need to support more than one instance.
At this moment OSS doesn't have any power management framework. All operating systems have different power management interfaces which has delayed development of power management in OSS. However driver designers should prepare for power management by separating hardware initialization from initialization of driver's data structures. In this way it will be easy to add power management after it becomes possible.
For the time being there is no publicly available sample source code for OSS drivers. The situation will change in the future after OSS gets released under some open source license.
The main limitation of this model is that all drivers need to be included in the OSS source tree and compiled together with the rest of the OSS package. Many key OSS structures may change their format between OSS builds and drivers compiled for different OSS versions are likely to corrupt the whole system.
To overcome these limitations we are working on a special OSSDDK interface that hides changes in the internal structures behind an object oriented programming interface. However for the time being OSSDDK is not available.
You should first do the initial preparations as defined in Creating an OSS driver project.