Boomer
Friday, March 13th, 2009Hi all,
Sun has published more details about Boomer that is their implementation of OSS4. Boomer is a hybrid based on Sun’s older SADA (/dev/audio) code and selected parts of OSS4. It probides full SADA support in addition to the OSS4 API (OSS4 itself has more or less limited SADA support). In addition Boomer supports many Solaris specific features such as fault management (FMA) that are not supported by OSS (yet).
Boomer is based on Sun’s existing low level drivers. Also large parts of the framework comes from Sun. This is OK. However there is some risk that Boomer behaves in slightly different way than OSS. My understanding is that applications written for OSS4 should work under Boomer out of box. However I suspect that applications written for Boomer may not work with our OSS4 implementation in all cases.
There are few main differences that may cause problems:
- Boomer doesn’t implement SNDCTL_DSP_SETFRAGMENT and application selectable fragment/buffer size that is preferred way for controlling latencies in OSS4. This should not be a problem in most cases since Boomer uses reasonably short fragment size. However there are special applications that would require very short fragments to work.
- Boomer makes the /dev/mixer API available to “ordinary” applications. OSS4 in turn bans use of the MIXER API from “ordinary” applications that use /dev/dsp too.
- The Boomer mixer API spec also tells that applications can use predefined control names (such as Mic, Line or whatever) for predefined purposes. OSS4 doesn’t have any predefined names and applications should handle the mixer API fully transparently. In OSS4 mixer control names are only meaningful to the user. The application should just show all the controls to the user and let him/her decide what they mean.
- Boomer has “flat” mixer interface. All mixer controls are in the same level. OSS4 in turn has hierarchical mixer structure where controls are organized as a tree.
- There may be places where Boomer differs from OSS unintentionally. Boomer has been tested with “legacy” OSS applications that have been written to be bug compatible with OSS/Free and ALSA’s OSS emulation. Unfortunately most of these applications use extremely complicated and brain dead non-blocking/timing strategies that make them very unreliable. OTOH Boomer should also have been tested with OSS4 applications such as osstest and ossplay/record so the situation should be under control.
- Boomer doesn’t implement many of the optional ioctl calls of OSS. This should not be a problem because they are listed as optional in the OSS4 API spec.
After all I don’t expect any major compatibility problems between OSS4 and Boomer. The audio API’s are supposed to be identical. The mixer API (ioctl calls) itself are identical too. However the way how Boomer implements the actual mixer behind the API is different. Possible compatibility problems can be avoided very easily. Applications just should continue to avoid using the mixer API even Boomer’s documentation says they can use it.