There are several updates to the case materials that the Boomer project
team would like to announce. I'll be modifying the actual documents
soon, but a quick summary here may be easier to read.
1) The audiosup (and related shim logic) has been removed. The project
team found it easy enough to just convert the native Solaris drivers to
first class Boomer native drivers that this work has been completed.
This eliminates extra processing and latency from the path for those
drivers that were still using the shim. (It also allowed some of those
drivers to more accurately express their hardware capabilities than was
previously possible.)
2) As a consequence of item #1, the SADA driver layer is completely
gone. Only boomer native drivers will be supported after Boomer integrates.
3) Exception to #2 above is Sun Ray audio, which doesn't use SADA. Sun
Ray audio will ultimately need to be converted as part of a follow on
project, but in the meantime, it can still be used with the legacy Sun
audio(7i) API. As Sun Ray is not supported on OpenSolaris (officially)
yet, the project team doesn't feel this is a big problem. The next
phase (which we will be working on soon) will add Sun Ray support, which
will be detailed in a separate PSARC case of its own.
4) Access to hardware controls is restricted to the OSS v4.x mixer API.
This means that only applications which understand the new style OSS
v4.x mixer API will be able to manage master hardware volumes, etc. A
Gstreamer plugin will be supplied for gnome applications such as
gnome-volume-control and mixer_applet2. Legacy Sun applications will
lose this ability. This is necessary because with some hardware the Sun
APIs were inadequate to support the full expression of device features.
(For example, many devices can have multiple monitors active, with
different gains, at the same time. A single monitor gain control can't
properly express this.)
5) For now, sdtaudiocontrol can be used to adjust per-application
volumes, and master record and playback volume, but not balance nor
monitor gain nor input or output port selection. The project team is
undertaking a separate LSARC case to EOF sdtaudiocontrol altogether.
gnome-volume-control is the replacement.
6) gnome-volume-control cannot display per-application volume settings
like sdtaudiocontrol's -ac option. Architecturally, nothing prevents us
from supporting this in gnome-volume-control, but it isn't clear that we
will have code to do this ready in time for integration of Phase I. If
anyone believes this feature regression is unacceptable for Phase I
delivery, then the project team would like to hear about it as soon as
possible.
7) The ability to use the command line options in audioplay and
audiorecord to adjust hardware settings (including record port, monitor
gain, and master hardware levels) is removed as part of #4 above. These
applications can still manage their own local playback and record gains,
but those settings affect only the particular instance of the
application that is using them. The switches which would attempt to
change master settings will be modified to issue a warning about their
use, but will otherwise be ignored.
8) mixerctl has grown the ability to access and manage all hardware
settings for these audio devices from the command line. An updated man
page will be posted in the commitment materials directory soon.
9) Per application volume controls, as well as "master PCM volume" are
implemented as monophonic values. Attempts to change balance will be
ignored. Balance of output levels of the master settings can be used by
adjusting individual speaker volumes using the OSS 4.x API. This change
is required to support multichannel audio. (Stereo levels don't make
sense with 5.1 audio, for example.) We believe that users need to
adjust the levels of different channels as a result of different speaker
positioning and volumes. We don't believe that a need to adjust balance
in one application independently from another application exists.
(However, the need to adjust the overall output volume in different
applications independently does exist.)
10) The monophonic master output volume control expressed in Boomer is
implemented as an attenuation of PCM data. It does not affect the
levels associated with any monitors. It will affect the volume of any
PCM data generated by the system regardless of whether it is played back
over analog or digital interfaces. (Legacy Sun drivers were not
consistent in how this was implemented. We believe Boomer's
implementation offers the least surprise to users.)
11) While the framework fully supports 192kHz (and possibly beyond) and
24-bit audio, the project team has not updated any of the drivers to
support this yet. It is unclear whether this work will be complete
before integration. (In many drivers, selection of higher frequencies
or bit resolutions must be made at the sacrifice of other features, such
as number of channels.) Architecturally this doesn't represent a change
-- its just a change in what we actually deliver at first integration.
(This could easily change if there is a key RFE to support high
definition audio.)
12) Many, many more devices now support multichannel audio in Boomer.
Some audioens hardware can support 4.0, and 5.1 is supported in capable
audio810, audiovia823x, and audioixp systems. 7.1 is supported on audiohd.
13) For now, the project team would like to limit the exposure of the
OSS API somewhat. Specifically, the project team would like to:
* restrict the new style 4.x mixer API to Consolidation/Contract
Private. We will work with the GStreamer team to get a contract in
place. We have some "constraints" on the names and values expressed in
this API, which will allow Gnome to provide better support for
localization and a11y than would otherwise be possible. (This will
require the Gnome team to #include an additional header file to import
the macros with the names.)
* restrict the old style 3.x mixer API to Obsolete Uncommited.
(Actually, we'd go further than that, and say that we're implementing it
only for compatibility, and only then a subset of functionality and
semantics, just enough to make existing legacy apps happy. We would
prefer developers not use this API in any new code. Our preference
would be not to document these APIs at all, or document them only with a
statement "for legacy compatibility only" and say nothing else about them.)
* mark much of the dsp API Obsolete Uncommitted. There are many,
many ioctls in the API. Many of which we don't think developers should
use (many of which are redundant or otherwise Obsolete.) Again, these
would preferably either be undocumented, or documented only in a form of
"don't use this in new code".
* the remaining OSS API, which should be sufficient to access all
the needs of any reasonable audio application, we would mark Uncommitted.
The full set of which portions of the API we believe should fall into
which classification will be posted later.
14) mmap(2) support is not being delivered in Phase I. This was already
detailed in the inception review materials.
Please let us know if there are any concerns about any of the above.
-- Garrett
