• E-Mail: ryan.beasley@gmail.com

TODO

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:

• AlexanderLeidinger for general and administrative questions.
• AriffAbdullah for specific, technical questions about the FreeBSD sound system.

• Initially, add support for all new ioctls introduced in the new API as stubs, still relying completely on the existing code.
• Write one or more utilities to control sound parameters using the new API. (This would phase out the sysctl interface in favor of new ioctls. Example operations may be enabling S/PDIF output, toggling DSP effects, etc. A measurable goal here is to have a tool(s) that support the most important, if not all, aspects of the new OSS API in charge of a card’s operating parameters.)
• Complete, as much as possible, the internal implementation necessary to fully support new features of the API.

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.

• So far, implemented ~20 ioctls, some fully supported and others with caveats. Biggest hurdles currently are (a) the primary/secondary buffers used for format/rate conversions (need to bypass this for “cooked” mode) and (b) individual drivers require minor tweaks to support things like handing over natively support capabilities.
• There are 8 ioctls of primary concern remaining, and all of the MIDI ones are on hold.
• A handful of ioctls remain in-flux, and 4Front has requested we not try to implement them. I'll still insert empty functions that end up returning EINVAL.
• Mixer extensions, while some of the coolest new features, are in-flux & also on hold. (These can be used to export hardware-specific features to userland. Cool stuff.)

• Eyeball current sys/soundcard.h and sound sources, and compare them to ioctls, etc. offered by new API.
• (Add details based on plan above.)
• ioctl reference
• thoughts regarding peak ioctls
• Short term goals

• Notes on locking in sound subsystem
• Things to discuss with other sound developers