IAM ====== Name: Boomer: Next Generation Solaris Audio Submitter: Garrett D'Amore Owner: Garrett D'Amore Interest: audio-oss-core@sun.com Status: inception scheduled 11/05/2008 Comment: preinception held 06/04/2008 Exposure: open Comment: Preinception discussion and potential impact on vendor relations must be private. The exposure will be changed to open prior to commitment. Comment: Old Name: OSS Audio for Solaris SUMMARY ======= ISSUES ====== djm-1 Please make sure you work with the VirtualBox team, there are known issues with lack of microphone support when Solaris is the VirtualBox *host*. This project needs to provide VirtualBox the capability to resolve that problem. Providing the OSS API may be sufficent. This issue is distinct from Solaris as a VirtualBox guest OS. answer: The VirtualBox host doesn't support the microphone, and from my own testing, only poorly supports playback, on Solaris today. We will be working with their team, as we believe that providing OSS APIs will make it easier for VirtualBox to fully support audio much as they do on Linux. (They should be able to ditch their use of Sun legacy APIs altogether.) djm-2 Sun Ray support. I'm glad you have thought about Sun Ray but I am also very disapointed it isn't in Phase 1 of this project. (there is some coverage of this in the 20qs submitted). At the very least for commitment review I want to know that the Sun Ray team has bought into this architecture and is actively engaged to quickly provide follow on support. Sun Ray audio is really important for a vast majority of Solaris users, particularly those running Windows via VirtualBox, SGD, VMware or some other virtual desktop infrastructure. Personally I think Sun Ray audio is higher priority than filling in the gaps in some hardware like the Creative SoundBlaster Live! (even though I own such hardware and would like to use it!). answer: We are quite serious about Sun Ray support, and see it as a gating item for ultimate completion of our goals. We are working on getting support for it in parallel, and hope to have it working in prototype form before year's end. We're also working with the Sun Ray team on this. However, the delivery model for Sun Ray is quite different from Solaris, and the additional work required to handle OSS APIs properly on Sun Ray (requiring additional architectural work) means that delivery of such may require additional time. djm-3 Interaction with the never delivered but approved PSARC/2005/274. answer: We will look into this -- I wasn't aware of this case, so thank you. Certainly, we expect to be expanding on the abilities of mixerctl, so there is no reason why this can't be done in a manner much like 2005/274 specified. If we do so, though, we'll probably want to expand on the settings other than just master play volume. Brussels persistence may offer a different model to follow. We'll have more to say on this at commitment. Note however that some desktop environments have per-user master settings that are saved across reboots. We anticipate that this may actually be more useful to most users. djm-4 Interaction with Device Allocation and Trusted Extensions. (there is some coverage of this in the 20qs submitted). The microphone and all other "input" channels (but not the outputs) are "security risk" in some environments. Trusted Extensions in particular. Even without Trusted Extensions enabled we have a device allocation framework allocate(1M)/deallocate(1M) that allows a user (a user at a given label (ie in a specific zone) for Trusted Extensions enabled configs) to get exclusive ownership of the audio device files. This case must not break this and must ensure that any new "input" channels are protected at least to the same level the microphone is in the current implementation. Note that this extends to Sun Ray DTUs as well (hence djm-2). answer: I've been researching this support in devfsadm (imagine my surprise at finding audio-specific hacks in devfsadm core!) and we are fully committed to ensuring that not only the legacy Sun APIs are covered by this, but also the new OSS APIs (which will have different device node names) are covered. THE NEXT STEP ============= -Do not regress the functionality that works today. -Meet with Gary and others to discuss and ensure that this project team can implement the security portion which is still being defined as both projects move ahead.