Ryan Beasley

Syncing with 4Front OSS v4 API



The OSS sound framework is the de-facto standard for portable sound support on Linux and many Unix platforms (BSDs, Solaris, etc.). FreeBSD implements an analog to this framework. 4Front Technologies recently released a new version of the API with some very interesting features, and FreeBSD will need some work to remain compatible.

My work would focus on the following tasks:

  1. Updating FreeBSD’s external sound API to match the OSS v4 specification. At this stage, the new API will just be a layer over the existing sound system, but will at least provide compatibility between FreeBSD and applications using the new API, even if the features are not yet supported.
  2. Updating or writing new userland applications included in the FreeBSD base system to make use of the new API where appropriate. (Among other things, Alexander suggested a single utility “to control non-mixer related aspects of the sound system, e.g. to switch to S/PDIF or enables hardwired DSP effects in the soundchip.”)
  3. Refining the sound system to fully support new features, and implementing the old API as a layer over the new to retain backwards compatibility. This last item may extend beyond the SoC program, but I fully intend to continue working on it.

Mentors from the FreeBSD Project:

Project Information


Project Schedule

The following are based on estimates received from Alexander. They are somewhat hazy because I don’t fully know either (a) the new OSS API, or (b) specifics on the internals of FreeBSD’s sound system.

  1. Determine differences between FreeBSD API and new OSS API. (Should only take a day or two of eyeballing header files & commentary vs. the OSSv4 developer manuals. New ioctls are flagged in blurbs about compatibility in the manual.)

  2. Analyze differences, determining if any are intentional (discussion with ariff@ and the multimedia@ mailing list). While waiting for feedback from others, will prime self on Perforce and continue to poke around and familiarize self as much as possible with the sound system internals. (I expect this to only take a few days while waiting for input.)
  3. Slow down and determine in what order elements of the new API are implemented. (Should take a day or less.)
  4. Write up rough implementation of new API over the old internals. (“The new mixer API is there but uses the old API internally and therefore doesn’t provide additional benefits.’) I’m expecting this to take 1.5-2.5 weeks.
  5. Start hashing out userland tools to take advantage of the new API. This work will be interleaved with #4 & #6, but I’m guessing should take less than a week.

  6. Refine implementation to support new features. (“The sound system is changed to fully utilize the new mixer API, and the old mixer API uses the new mixer API internally to provide backward compatibility.”) The remainder of time will be going to complete as much of this as possible.

Project Status




RyanBeasley (last edited 2022-10-05T23:36:20+0000 by KubilayKocak)