#ident "@(#)issues 1.7 09/03/03 SAC" PSARC 2008/318: Boomer: Next Generation Solaris Audio Submitter: Garrett D'Amore Owner: Garrett D'Amore Intern: Phi Tran Issues for inception (11/05/2008): 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. update: See gw-1. Note that I don't believe that device allocation does anything special for recording today. If you allocate a device, you give both record and playback access. (That said, potentially this could be controlled with device permissions. You have to open with FREAD to do recording. That's true in both Boomer and legacy Sun audio.) gw-1 Audio Object Reuse / device management (allocation) issues (Let's take this off line -- send me a note so we can get together) answer: Gary and I have talked about this. Boomer will be supplying a device_clean script, and is doing the right thing for DA_AUDIO. There are also bugs in the device allocation framework itself, but they're out of scope for Boomer to fix (CR has been filed.) PSARC 2008/318: Boomer: Next Generation Solaris Audio Submitter: Garrett D'Amore Owner: Garrett D'Amore Intern: Phi Tran Issues for commitment (03/04/2009): jdc-1 Should 'sdtaudiocontrol' be yanked out of Nevada before Boomer delivery, or does nobody care? (Non-goal #4.) answer Good question. It seems like nobody much cares about "Nevada" anymore, and sdtaudiocontrol is not part of "Indiana". I don't care that much one way or the other. I was going to try to get it removed asap anyway, I just hadn't planned on treating such removal as a pre-requisite. jdc-2 Digital telephone interfaces are inherently 8-bit mu-law PCM (or A-law in Europe). Should Boomer be able to support those sorts of devices? (Non-goal #12 says not.) answer We support both of those formats. Its not inherently impossible to make them work with Boomer, and we've not knowingly excluded them. But we've neither gone out of our way to support them either. jdc-3 What becomes of the audioplay and audiorecord command line options? Is there an EOF? Why is ignoring them ok? (Should the man pages at least be updated?) answer I've not scheduled a separate EOF for them. The problem of audioplay & audiorecord's command line options is that they are still stuck with the limitations of the Sun audio(7i) api, and so can't express properly advanced features like multiple simultaneous monitors. Additionally, the idea that these applications should change the master system volume is IMO a significant bug. The volume levels should only apply to the application itself. If you want to change master system volume, use a mixer panel tool (or mixerctl) to do so. jdc-4 Are there any third-party drivers that used the SADA DDI? answer Yes. The ones I know about are freeware drivers from Jurgen Keil, and 4Front's OSS implemenation. Jurgen's drivers for ESS1370, 1371, and 1373 are fully replaced by audiopci and audioens. His driver for the EMU10K parts (aka audigy) does not have a counterpart in Boomer *yet*. But it will soon. It does not look like this will happen in time for phase I, but should be an easy post-integration RFE. The 4Front drivers are rather intrusive in the system, and their use of SADA is "limited" at best. I have no plans or desire to enable kernel-level compatibility with these drivers. They will break. However: it will be *much* easier for 4Front to adapt their system to work well with Boomer, than it ever was with SADA. jdc-5 20q9: "start of day"? Why once a day? answer Sorry, that should have read "at system boot". Its a mistake of my terminology -- I often say "start of day" when I mean "system startup". The service only runs during system boot.