It looks like none of the OSS CLI will be part of this phase. How will volume control be done? Does the Solaris audio CLI and Gnome volume control work with OSS hdaudio driver?
Margot Frank Che wrote: > I'm sponsoring this fast track for Freeman Liu and the audio team. > The requested binding is minor. The timer is set to 01/29/2008. > > ------------------------------------------------------------------------------------------------ > > > > 4.Technical Description > > This project is phase 1 of the umbrella project described in > "Open Sound System (OSS) for Solaris" (PSARC 2007/238) > There are two main goals of this phase. One is to integrate OSS high > definition audio driver "hdaudio" into Solaris to support the most > popular audio hardware. The other goal is to keep SADA > (Solaris Audio Driver Architecture) compatibility so that there will > be no regression for the current SADA applications. > > Theoretically, all the HD audio hardware will be supported. We will test > the ones supported by SADA HD audio driver to prevent regression. > Several > other popular codecs will also be covered. > > The SADA compatibility is accomplished by an emulation layer named > "sadasupport". It is a pseudo SADA audio driver which provides SADA > interface to upper level. From the applications' point of view, it > is not different from other SADA drivers. On the other hand, it does > not operate the hardware directly. Instead, it accesses the device file > provided by the lower level OSS drivers through ldi interface. The > following diagram illustrates the relations between SADA framework, > sadasupport, OSS framework and OSS driver where there is a HD audio > hardware in the system > > |-------------| > User level |app1,app2 ...| > |------+------| > |(1) > | > |-----+----| |--------| > -------------------|/dev/audio|-----------------|/dev/dsp|------------------ > > |-----+----| |-+--+---| > |(2) (4) | | > Kernel level | +--------------------+ |(5) > | | | > |--------------|(3)|-----+---+-| > |---+---|(6)|-------------| > |SADA framework+---+sadasupport| |hdaudio+---+OSS > framework| > |--------------| |-----------| |---+---| > |-------------| > |(7) > |---+----| > |HD audio| > |hardware| > |--------| > > * (1),(2) Applications make audio requests through /dev/audio, > which is exported by sadasupport. > * (3) Sadasupport turns to SADA framework to fulfill the requests > * (4),(5) Sadasupport access hdaudio driver by ldi interface when > it needs service from hdaudio driver to complete the requests > * (6),(7) Hdaudio turn to OSS framework to fulfill the requests > and operate the hardware when needed. > > In phase 1, the device file "/dev/dsp" provided by OSS drivers is a > project private interface and only root user is able to access it. > No new interface will be published in this phase. Although HD audio > driver is replaced by OSS hdaudio driver, other SADA drivers will not > be replaced in phase 1. Drivers of the two different frameworks can work > together. SADA framework will not be removed, either. Detailed > information > of SADA can be found in man pages: audio(7I), mixer(7I) and > audio_support(7I). > > Summarily, we use OSS hdaudio driver to support HD audio hardware > and use sadasupport to maintain SADA compatibility. > > During the discussion of the umbrella case, the issue of latency has > been brought up. In this context, latency means the time gap between > the time hardware/driver is changed by other applications or by external > events and the time when applications sense it. And it should be > achieved without high CPU usage. It can be achieved by leverage > feature provided by SADA interface. Since SADA interface will be kept, > latency issues is addressed naturally. Consensus was reached during > the offline discussion. > > Here is the list of all kernel module and driver files: > osscommon > osscore > osscore.conf > sadasupport > sadasupport.conf > vmix > vmix.conf > hdaudio > hdaudio.conf > > Some of the tunables provided by the .conf files are for changing > some aspect of the OSS system. But the default value is suitable > in most case and they rarely need to be changed. Other tunable are > for debugging. > > All these files and the tunables are of project private stability in > this > phase. They might be changed in the following phases. > > 5. Reference Documents: > > Open Sound System (OSS) for Solaris (PSARC 2007/238). > http://opensolaris.org/os/project/opensound > > > >
