From sacadmin Mon Oct 27 12:36:35 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9RJaYOk018247 for ; Mon, 27 Oct 2008 12:36:35 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9RJaTlP005175 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Tue, 28 Oct 2008 03:36:34 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9E0040BX4XZ400@brm-avmta-1.central.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 27 Oct 2008 13:36:33 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9E001LAX4WLX20@brm-avmta-1.central.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 27 Oct 2008 13:36:32 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9RJaWsY021315 for ; Mon, 27 Oct 2008 12:36:32 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9E00J01X2DWR00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for psarc@sun.com (ORCPT psarc@sun.com); Mon, 27 Oct 2008 12:36:32 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9E00BZ4X4QXS90@fe-sfbay-09.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 27 Oct 2008 12:36:26 -0700 (PDT) Date: Mon, 27 Oct 2008 12:32:08 -0700 From: "Garrett D'Amore" Subject: PSARC 2008/318 Boomer: Next Generation Solaris Audio Sender: Garrett.Damore@sun.com To: psarc@sun.com Message-id: <49061738.3070701@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1596 I have redacted pretty much the entire mail file from the preinception discussion. Sun folks are free to look in the closed/ directory for the detailed history, but I want to take a moment to provide a replacement synopsis for the "open" mail file. 1) Sun has licensed technology from 4Front for Open Sound System audio. 2) For a long list of reasons (not listed here, but more detail forthcoming, and a lot in the closed file) 4Front's code is not suitable for integration into Solaris as-is. 3) Due to differing business goals between 4Front and Sun/OpenSolaris, it is not practical to expect that upstream (4Front) can just accept our changes. The changes are too large, and would compromise other markets that 4Front services besides Solaris. 4) The code has diverged dramatically -- Boomer (new code name) represents a substantial divergence in implementation from either 4Front OSS or Sun SADA. 5) Discussion of whether ALSA was a better target API was made. The project team's belief is that ALSA is not widely used (at least not by applications directly), and concerns about possible licensing restrictions make this a less desirable alternative for right now. Everything else that was discussed that I've redacted is either obsolete information, or will be restated in our forthcoming case materials, so I don't think any information will be lost. At this point, any further discussion in this case should be treated as "Open" public information. If anyone has any concerns not suitable for open exposure, please e-mail offline. Thank you. -- Garrett From gdamore@sun.com Mon Oct 27 16:01:44 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9RN1hmo026611 for ; Mon, 27 Oct 2008 16:01:43 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m9RN1ZX3008556 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 27 Oct 2008 23:01:42 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9F00K016MSY300@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Oct 2008 17:01:40 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9F001N16MRLXC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Oct 2008 17:01:39 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9RN1dAO017137 for ; Mon, 27 Oct 2008 16:01:39 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9F00F016I1ZE00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Oct 2008 16:01:39 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9F00ATL6MQJC20@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 27 Oct 2008 16:01:39 -0700 (PDT) Date: Mon, 27 Oct 2008 15:57:19 -0700 From: "Garrett D'Amore" Subject: PSARC 2008/318 Boomer: Next Generation Solaris Audio Sender: Garrett.Damore@sun.com To: PSARC-ext Message-id: <4906474F.2040404@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1322 In anticipation of next week's PSARC inception for this project, I've started populating case materials in the inception.materials directory. This stuff is still a bit rough around the edges, and we'll be populating more in there soon (and probably revising materials -- some diagrams showing relationships sill need to be created), but in the interest of making more available for perusal sooner, I'm posting now. Those of you who may have had an interest in "OSS" or Open Sound System should be aware that this is the same project, so you should have a look. gd78059@sac{98}> ls -la inception.materials/ total 343 drwxrwsr-x 2 gd78059 sac 8 Oct 27 15:47 . drwxrwsr-x 8 gd78059 sac 12 Oct 27 12:38 .. -rw-r--r-- 1 gd78059 sac 15229 Oct 27 15:26 ac97.h -rw-r--r-- 1 gd78059 sac 9531 Oct 27 15:26 audio_client.h -rw-r--r-- 1 gd78059 sac 10575 Oct 27 15:26 audio_common.h -rw-r--r-- 1 gd78059 sac 7419 Oct 27 15:26 audio_driver.h -rw-r--r-- 1 gd78059 sac 9936 Oct 27 15:47 boomer.20q -rw-r--r-- 1 gd78059 sac 113106 Oct 27 15:29 boomer.pdf Note that this case also had a closed preinception (which was closed for business reasons), but I've redacted those materials, and the rest of this case will be open. -- Garrett From gdamore@sun.com Tue Oct 28 15:43:17 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m9SMhGrn014083 for ; Tue, 28 Oct 2008 15:43:16 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m9SMhEKY025196 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 29 Oct 2008 06:43:15 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9H00A070G1SN00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Oct 2008 15:43:13 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9H003II0G1POD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Oct 2008 15:43:13 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9SMhDZK027611 for ; Tue, 28 Oct 2008 15:43:13 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9H0050102DTB00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Oct 2008 15:43:13 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9H00IPN0G0IP00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 28 Oct 2008 15:43:12 -0700 (PDT) Date: Tue, 28 Oct 2008 15:38:48 -0700 From: "Garrett D'Amore" Subject: PSARC 2008/318 Boomer: Next Generation Solaris Audio Sender: Garrett.Damore@sun.com To: PSARC-ext Message-id: <49079478.5070805@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 780 I've added a set of slides (boomer-inception.pdf) and updated the spec document (boomer.pdf) in the inception.materials directory. gd78059@sac{6}> ls -la total 1144 drwxrwsr-x 2 gd78059 sac 9 Oct 28 15:40 . drwxrwsr-x 8 gd78059 sac 12 Oct 27 12:38 .. -rw-r--r-- 1 gd78059 sac 15229 Oct 27 15:26 ac97.h -rw-r--r-- 1 gd78059 sac 9531 Oct 27 15:26 audio_client.h -rw-r--r-- 1 gd78059 sac 10575 Oct 27 15:26 audio_common.h -rw-r--r-- 1 gd78059 sac 7419 Oct 27 15:26 audio_driver.h -rw-r--r-- 1 gd78059 sac 285780 Oct 28 15:40 boomer-inception.pdf -rw-r--r-- 1 gd78059 sac 9936 Oct 27 15:47 boomer.20q -rw-r--r-- 1 gd78059 sac 126873 Oct 28 15:41 boomer.pdf Enjoy! -- Garrett From gdamore@sun.com Mon Nov 3 07:46:31 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mA3FkVOm007559 for ; Mon, 3 Nov 2008 07:46:31 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mA3Fjwsr017249 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 3 Nov 2008 07:46:31 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9R0070FL5GVJ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 07:46:28 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9R003RTL57X0B0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 07:46:19 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mA3FkI7b022826 for ; Mon, 03 Nov 2008 07:46:18 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9R00K01L0SRY00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 07:46:18 -0800 (PST) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9R004CGL56PHC0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 07:46:18 -0800 (PST) Date: Mon, 03 Nov 2008 07:41:32 -0800 From: "Garrett D'Amore" Subject: PSARC 2008/318 Boomer - potential issues Sender: Garrett.Damore@sun.com To: PSARC-ext Message-id: <490F1BAC.1040001@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 4527 I wanted to record some potential issues we've found. This stuff needs to be in our case materials before final commitment review, but at some level, we've not decided how to handle all of them, so I'd appreciate it if anyone has any special insight. 1) Port definitions and Sun audio(7I). Sun APIs has definitions for a number of possible output ports, but the full set is less than what OSS, or even modern hardware, can express. For example, there can be additional auxiliary input and outputs, video input, etc. The Sun APIs could easily be expanded to include the additional ports we have so far, since there are plenty of bits left in the bit array. The problem is that legacy applications may not be coded with knowledge of these bits, and I'm not sure how they will react in the presence of additional bits. I'm inclined to just go ahead and add new port definitions anyway, and file bugs against applications that break as a result. Does anyone have any additional suggestions? If the ability to query or change port settings (at least with values that reflect actual hardware settings) is reserved for control applications, then perhaps this limitation will go away -- see point 6 below. 2) Expression of additional kinds of volume controls and Sun APIs. If an application, such as sdtaudiocontrol, uses the Sun APIs to manage levels of a "foreign" (e.g. OSS) application, it may not be able to control all of the virtual levels associated with the application. (Because Sun's rather simplistic API consists solely of a single gain and balance.) I think that as part of our implementation, we will convert the main control applications to the full featured OSS API, and just punt on this problem -- control applications using Sun audio(7i) won't be able to adjust surround levels, etc. 3) An alternate option would be for us to expand the ioctls for the legacy Sun API to include support for these other channels. In fact, for *playing*, there is no real inherent limitation in the Sun APIs. The issue comes in the implementation, and in the *control* API. (You can stream as many channels as you want with the Sun API, but you can't adjust levels for more than 2 channels.) I'm inclined for now to punt on this, and push applications towards OSS (wants we are ready to bless OSS as a committed API.) 4) Multiple inputs. There is no real restriction on the number of inputs that can be active at a time. E.g. you could be mixing a CD and a microphone input at the same time (think Karaoke). Sun APIs don't support this. Again, this isn't a problem for regular apps, because they don't expect to be able to do this -- but control apps only. I'm again thinking that control apps should be written to the OSS API. 5) Separation of monitor sources and record sources. Many chips (most?) allow the set of monitor devices to be selected independently of the set of record devices. So you could be playing music from a CD, but only 'recording' the input from a headset mic being used for VoIP. Sun can't express this. Again, only an issue for control apps. 6) This seems to be leading us toward the road that we should, once OSS APIs become available everywhere, deprecate the use of Sun audio for mixer and control applications. 7) Potential power(9e) regression for legacy device drivers. Right now, for some legacy SPARC devices (e.g. audiocs, audiots), our work to convert these devices to "Boomer native" devices has been done, but we have not done the work to make these devices fully support power(9e). (There are some challenges here, because the pm interfaces are not safe to call in streams context, an area that was a latent bug in some of the audio drivers!) While we could tackle this, we believe there is little merit in the effort involved -- the amount of actual power saved is probably quite small, particularly relative to the power consumed by the CPUs on these systems. We'd prefer to skip this effort, and take the small regression. This might take some of these systems out of energystar v2 compliance, but as we believe that these systems are not in use in applications that are sensitive to power consumption, and as they are no longer marketed, we don't believe this should be a serious problem for anyone. If anyone feels strongly otherwise, we'd like to know. (Note that we do support platform power management via suspend-to-disk on the platforms that are capable of it.) Thanks. -- Garrett From Neal.Pollack@Sun.COM Mon Nov 3 09:35:21 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mA3HZKUv010860 for ; Mon, 3 Nov 2008 09:35:21 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mA3HZGqF027821 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 3 Nov 2008 17:35:19 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9R00B0NQ6VT600@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 09:35:19 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9R009H0Q6T0TD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 09:35:17 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mA3HZHgr005569 for ; Mon, 03 Nov 2008 09:35:17 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9R00F01PQCKX00@fe-sfbay-09.sun.com> (original mail from Neal.Pollack@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 09:35:17 -0800 (PST) Received: from [10.1.48.130] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9R00679Q6QK300@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 09:35:14 -0800 (PST) Date: Mon, 03 Nov 2008 09:34:51 -0800 From: Neal Pollack Subject: Re: PSARC 2008/318 Boomer - potential issues In-reply-to: <490F1BAC.1040001@sun.com> Sender: Neal.Pollack@Sun.COM To: "Garrett D'Amore" Cc: PSARC-ext Message-id: <490F363B.1030305@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <490F1BAC.1040001@sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081014) Status: RO Content-Length: 1465 On 11/03/08 07:41, Garrett D'Amore wrote: > > > 7) Potential power(9e) regression for legacy device drivers. Right > now, for some legacy SPARC devices (e.g. audiocs, audiots), our work > to convert these devices to "Boomer native" devices has been done, but > we have not done the work to make these devices fully support > power(9e). (There are some challenges here, because the pm interfaces > are not safe to call in streams context, an area that was a latent bug > in some of the audio drivers!) While we could tackle this, we > believe there is little merit in the effort involved -- the amount of > actual power saved is probably quite small, particularly relative to > the power consumed by the CPUs on these systems. We'd prefer to skip > this effort, and take the small regression. This might take some of > these systems out of energystar v2 compliance, Which model sparc desktops are you talking about? You may want to check, because they may be EOL'ed already anyway if they are old enough models. Neal > but as we believe that these systems are not in use in applications > that are sensitive to power consumption, and as they are no longer > marketed, we don't believe this should be a serious problem for > anyone. If anyone feels strongly otherwise, we'd like to know. > (Note that we do support platform power management via suspend-to-disk > on the platforms that are capable of it.) > > Thanks. > > -- Garrett From gdamore@sun.com Mon Nov 3 09:45:36 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mA3HjZ8q011058 for ; Mon, 3 Nov 2008 09:45:36 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mA3HjYZV003590 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 3 Nov 2008 17:45:35 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9R00C07QNY4G00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 09:45:34 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9R00C5AQNT1H00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 09:45:34 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mA3HjOJD006819 for ; Mon, 03 Nov 2008 09:45:29 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9R00101PLWZY00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 09:45:24 -0800 (PST) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9R005QOQLW1DE0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 09:44:22 -0800 (PST) Date: Mon, 03 Nov 2008 09:39:32 -0800 From: "Garrett D'Amore" Subject: Re: PSARC 2008/318 Boomer - potential issues In-reply-to: <490F363B.1030305@Sun.Com> Sender: Garrett.Damore@sun.com To: Neal Pollack Cc: PSARC-ext Message-id: <490F3754.7060300@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <490F1BAC.1040001@sun.com> <490F363B.1030305@Sun.Com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 2920 Neal Pollack wrote: > On 11/03/08 07:41, Garrett D'Amore wrote: >> >> >> 7) Potential power(9e) regression for legacy device drivers. Right >> now, for some legacy SPARC devices (e.g. audiocs, audiots), our work >> to convert these devices to "Boomer native" devices has been done, >> but we have not done the work to make these devices fully support >> power(9e). (There are some challenges here, because the pm >> interfaces are not safe to call in streams context, an area that was >> a latent bug in some of the audio drivers!) While we could tackle >> this, we believe there is little merit in the effort involved -- the >> amount of actual power saved is probably quite small, particularly >> relative to the power consumed by the CPUs on these systems. We'd >> prefer to skip this effort, and take the small regression. This >> might take some of these systems out of energystar v2 compliance, > > Which model sparc desktops are you talking about? > You may want to check, because they may be EOL'ed already anyway if > they are old enough models. Right now we're talking about models as recent as the SunBlade 2500, and as old as the Sun Ultra 2. We "support" all of these today. (For some value of "support" -- i.e. the software loads and runs.) Since this isn't being considered for backport to Solaris 10, I don't believe any of the above concern impacts any contractual support obligations. ("OpenSolaris" isn't supported on SPARC at all, at present. And the various IP issues surrounding framebuffers may make it nigh impossible for some of them to *ever* be properly supported under OpenSolaris. And any guesses about a hypothetical Solaris 11 release are just that -- guesses and hypothetical. All that said, I want to provide basically the same user accessible feature set for these platforms on OpenSolaris, for as long as they are part of OpenSolaris. I'm just not sure how commonly used this particular feature ever was, and I doubt many, if any, would miss pm support for these devices on OpenSolaris. Conversely, not providing audio support at all on those platforms would probably represent a much graver feature regression. And its not the case that there are any technical reasons preventing full implementation of power(9e), my desire here is mostly to constrain the problem so that the resources we have at hand can remain focused on the more important parts of this project.) -- Garrett > > Neal > > >> but as we believe that these systems are not in use in applications >> that are sensitive to power consumption, and as they are no longer >> marketed, we don't believe this should be a serious problem for >> anyone. If anyone feels strongly otherwise, we'd like to know. >> (Note that we do support platform power management via >> suspend-to-disk on the platforms that are capable of it.) >> >> Thanks. >> >> -- Garrett > > From bart.smaalders@sun.com Mon Nov 3 10:44:54 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mA3IisY5013675 for ; Mon, 3 Nov 2008 10:44:54 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mA3Iiq6p019594; Mon, 3 Nov 2008 10:44:54 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9R0040PTETGX00@brm-avmta-1.central.sun.com>; Mon, 03 Nov 2008 11:44:53 -0700 (MST) Received: from zion.sfbay.sun.com ([129.146.17.75]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9R00L2TTES0GC0@brm-avmta-1.central.sun.com>; Mon, 03 Nov 2008 11:44:53 -0700 (MST) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id mA3IipbG013609; Mon, 03 Nov 2008 18:44:51 +0000 (GMT) Date: Mon, 03 Nov 2008 10:44:50 -0800 From: Bart Smaalders Subject: Re: PSARC 2008/318 Boomer - potential issues In-reply-to: <490F1BAC.1040001@sun.com> To: "Garrett D'Amore" Cc: PSARC-ext Message-id: <490F46A2.6000102@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <490F1BAC.1040001@sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080908) Status: RO Content-Length: 638 Garrett D'Amore wrote: > 6) This seems to be leading us toward the road that we should, once OSS > APIs become available everywhere, deprecate the use of Sun audio for > mixer and control applications. Your proposal seems to be a very reasonable approach for the next Solaris release: continue to support application level use (playback, record) of legacy Sun audio apis, but require use of OSS interfaces for systemic control. Thanks for taking this on. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From gdamore@sun.com Mon Nov 3 11:04:20 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mA3J4KYw014512 for ; Mon, 3 Nov 2008 11:04:20 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mA3J4Cbn014187 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 3 Nov 2008 11:04:20 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9R00531UB6QY00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 12:04:18 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9R00LW8UB50GE0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 12:04:17 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mA3J4HuA017723 for ; Mon, 03 Nov 2008 11:04:17 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9R00401RAIWP00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 11:04:17 -0800 (PST) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9R0037FUAV8AL0@fe-sfbay-09.sun.com>; Mon, 03 Nov 2008 11:04:07 -0800 (PST) Date: Mon, 03 Nov 2008 10:59:18 -0800 From: "Garrett D'Amore" Subject: Re: PSARC 2008/318 Boomer - potential issues In-reply-to: <490F46A2.6000102@Sun.COM> Sender: Garrett.Damore@sun.com To: Bart Smaalders Cc: PSARC-ext Message-id: <490F4A06.4000200@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <490F1BAC.1040001@sun.com> <490F46A2.6000102@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 632 Bart Smaalders wrote: > Garrett D'Amore wrote: > >> 6) This seems to be leading us toward the road that we should, once >> OSS APIs become available everywhere, deprecate the use of Sun audio >> for mixer and control applications. > > > Your proposal seems to be a very reasonable approach for the > next Solaris release: continue to support application level use > (playback, record) of legacy Sun audio apis, but require use of > OSS interfaces for systemic control. > > Thanks for taking this on. Thanks for your support, as well. :-) I'm certainly leaning in this direction, at the moment. - Garrett > > - Bart > > From Brian.Cameron@sun.com Mon Nov 3 14:04:18 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mA3M4Ia8020635 for ; Mon, 3 Nov 2008 14:04:18 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mA3M4DkI024076 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 3 Nov 2008 14:04:18 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9S00I292N5W000@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 15:04:17 -0700 (MST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9S00I422N4U300@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 15:04:16 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mA3M4GeT003550 for ; Mon, 03 Nov 2008 22:04:16 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9S00H011ADIH00@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 15:04:16 -0700 (MST) Received: from [192.168.1.104] ([67.167.207.170]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9S002R72MY35F0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 15:04:14 -0700 (MST) Date: Mon, 03 Nov 2008 16:03:42 -0600 From: Brian Cameron Subject: Re: PSARC 2008/318 Boomer - potential issues In-reply-to: <490F1BAC.1040001@sun.com> Sender: Brian.Cameron@sun.com To: "Garrett D'Amore" Cc: PSARC-ext Message-id: <490F753E.6080500@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <490F1BAC.1040001@sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 1061 Garrett: > I think that as part of our implementation, we will > convert the main control applications to the full featured OSS API, and > just punt on this problem -- control applications using Sun audio(7i) > won't be able to adjust surround levels, etc. > > 6) This seems to be leading us toward the road that we should, once OSS > APIs become available everywhere, deprecate the use of Sun audio for > mixer and control applications. Since GStreamer supports a plugin-in approach, it can support both SunAudio and OSS and let the user pick which mixer controls they want to use in gnome-volume-control at run time. The only question is which should be used by default. As you say, in the long run, OSS makes the most sense. One factor which could affect the default choice is Sun Ray. I am not sure we can switch to using OSS mixing controls by default until the Sun Ray support is done. Otherwise, won't audio just break for any Sun Ray users? Maybe we don't care, but I thought we were trying to promote Sun Ray usage on OpenSolaris. Brian From gdamore@sun.com Mon Nov 3 14:47:38 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mA3Mlcxj021505 for ; Mon, 3 Nov 2008 14:47:38 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mA3Mlca4012082 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 3 Nov 2008 14:47:38 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9S0000H4NEEN00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 14:47:38 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9S00KGX4NDJC60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 14:47:37 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mA3MlbYd014229 for ; Mon, 03 Nov 2008 14:47:37 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9S00B0145SIS00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 14:47:37 -0800 (PST) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9S009EZ4N7D5H0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 14:47:31 -0800 (PST) Date: Mon, 03 Nov 2008 14:42:42 -0800 From: "Garrett D'Amore" Subject: Re: PSARC 2008/318 Boomer - potential issues In-reply-to: <490F753E.6080500@sun.com> Sender: Garrett.Damore@sun.com To: Brian Cameron Cc: PSARC-ext Message-id: <490F7E62.6010201@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <490F1BAC.1040001@sun.com> <490F753E.6080500@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 2628 Brian Cameron wrote: > > Garrett: > >> I think that as part of our implementation, we will convert the main >> control applications to the full featured OSS API, and just punt on >> this problem -- control applications using Sun audio(7i) won't be >> able to adjust surround levels, etc. >> >> 6) This seems to be leading us toward the road that we should, once >> OSS APIs become available everywhere, deprecate the use of Sun audio >> for mixer and control applications. > > Since GStreamer supports a plugin-in approach, it can support both > SunAudio and OSS and let the user pick which mixer controls they want to > use in gnome-volume-control at run time. The only question is which > should be used by default. As you say, in the long run, OSS makes the > most sense. > > One factor which could affect the default choice is Sun Ray. I am not > sure we can switch to using OSS mixing controls by default until the Sun > Ray support is done. Otherwise, won't audio just break for any Sun Ray > users? Maybe we don't care, but I thought we were trying to promote > Sun Ray usage on OpenSolaris. Sun Ray is in fact the only hold out here. We're working in parallel on Sun Ray support, but there are some issues with Sun Ray support: 1) Sun Ray isn't supported officially on OpenSolaris yet. And the Sun Ray team hasn't given me a time frame for when it will be. 2) There is additional complexity in the code, that might required a phased delivery. 3) There is a substantial challenge for OSS applications (the OSS API) on Sun Ray. That is, these applications have not been coded to look for $AUDIODEV in the environment file. So we need to have some kind of virtual device in the kernel to reroute audio to the userland utaudio daemon associated with the user's session. *That* requires a mechanism to be able to identify the Sun Ray session a process should be running under, which means some new API and probably a new field or two in the uarea. And *that* is an architectural change that will need to be designed and reviewed separately. So, the above issues result in us "deferring" Sun Ray support to Phase 2. Note that if we only have to support GStreamer, and if GStreamer is willing to identify the Sun Ray session ID for us (e.g. with a new ioctl, or by opening a different file), then we could make those APPs work fairly easily. I was trying to find a solution which didn't rely on modification of userland code, though. (I have hypothesized that there are interesting audio applications which use OSS, and which are not based on GStreamer.) -- Garrett > > Brian > From Brian.Cameron@sun.com Mon Nov 3 15:02:10 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mA3N29tY023472 for ; Mon, 3 Nov 2008 15:02:09 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mA3N23BU000531 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 3 Nov 2008 16:02:09 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9S00G2H5BKJB00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 15:02:08 -0800 (PST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9S006CK5BJ2980@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 15:02:07 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mA3N27vD023286 for ; Mon, 03 Nov 2008 23:02:07 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9S000014S3XK00@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 16:02:07 -0700 (MST) Received: from [192.168.1.104] ([67.167.207.170]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9S002T25BGRYA0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 16:02:04 -0700 (MST) Date: Mon, 03 Nov 2008 17:01:35 -0600 From: Brian Cameron Subject: Re: PSARC 2008/318 Boomer - potential issues In-reply-to: <490F7E62.6010201@sun.com> Sender: Brian.Cameron@sun.com To: "Garrett D'Amore" Cc: PSARC-ext Message-id: <490F82CF.9090802@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <490F1BAC.1040001@sun.com> <490F753E.6080500@sun.com> <490F7E62.6010201@sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 1020 Garrett: > Note that if we only have to support GStreamer, and if GStreamer is > willing to identify the Sun Ray session ID for us (e.g. with a new > ioctl, or by opening a different file), then we could make those APPs > work fairly easily. I was trying to find a solution which didn't rely > on modification of userland code, though. (I have hypothesized that > there are interesting audio applications which use OSS, and which are > not based on GStreamer.) GStreamer based programs can easily be confiugred to work with either SADA or OSS. All other audio programs in Solaris (such as Flash, RealPlayer, and Ekiga) talk directly to SADA. There are some interesting OSS audio applications that are not based on GStreamer - an example is audacity. However, there are not any such programs currently distributed with Solaris. If we were to modify programs like Flash, RealPlayer or Ekiga so they worked with OSS, then I would bet we would make them talk directly to OSS rather than via GStreamer. Brian From Artem.Kachitchkin@sun.com Mon Nov 3 15:47:42 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mA3NlgfB024529 for ; Mon, 3 Nov 2008 15:47:42 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mA3NlZpf002043 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 3 Nov 2008 15:47:42 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9S0030D7FHO600@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 16:47:41 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9S00IJP7FHU380@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 16:47:41 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mA3Nlfod020693 for ; Mon, 03 Nov 2008 15:47:41 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9S003016VA3M00@fe-sfbay-10.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 15:47:41 -0800 (PST) Received: from [129.146.104.83] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9S00IOC7F7BLD0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 15:47:31 -0800 (PST) Date: Mon, 03 Nov 2008 15:46:56 -0800 From: Artem Kachitchkine Subject: Re: PSARC 2008/318 Boomer - potential issues In-reply-to: <490F7E62.6010201@sun.com> Sender: Artem.Kachitchkin@sun.com To: "Garrett D'Amore" Cc: Brian Cameron , PSARC-ext Message-id: <490F8D70.6050502@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <490F1BAC.1040001@sun.com> <490F753E.6080500@sun.com> <490F7E62.6010201@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 222 > to be able to identify the Sun Ray session a process should be running > under, which means some new API and probably a new field or two in the > uarea. And subsystems other than audio could benefit as well. -Artem From gdamore@sun.com Mon Nov 3 16:05:21 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mA405KHL026399 for ; Mon, 3 Nov 2008 16:05:21 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mA405IWI026555 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 4 Nov 2008 00:05:19 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9S0000788UK800@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 16:05:18 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9S0063Z88U22D0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 16:05:18 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mA405I1o022685 for ; Mon, 03 Nov 2008 16:05:18 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9S00L01801VI00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 16:05:18 -0800 (PST) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9S00EC888H5240@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 03 Nov 2008 16:05:06 -0800 (PST) Date: Mon, 03 Nov 2008 16:00:16 -0800 From: "Garrett D'Amore" Subject: Re: PSARC 2008/318 Boomer - potential issues In-reply-to: <490F8D70.6050502@sun.com> Sender: Garrett.Damore@sun.com To: Artem Kachitchkine Cc: Brian Cameron , PSARC-ext Message-id: <490F9090.5070200@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <490F1BAC.1040001@sun.com> <490F753E.6080500@sun.com> <490F7E62.6010201@sun.com> <490F8D70.6050502@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 433 Artem Kachitchkine wrote: > >> to be able to identify the Sun Ray session a process should be >> running under, which means some new API and probably a new field or >> two in the uarea. > > And subsystems other than audio could benefit as well. Indeed. And if we design it right, it could have applications outside of Sun Ray. (Think, for example, of "virtual" displays associated with different VNC clients.) -- Garrett From Darren.Moffat@Sun.COM Tue Nov 4 02:30:07 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mA4ATvbx011061 for ; Tue, 4 Nov 2008 02:30:07 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mA4ATq8v021539 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 4 Nov 2008 02:29:52 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K9T0090115RMU00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 Nov 2008 03:29:51 -0700 (MST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K9T00HW315Q0JA0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 Nov 2008 03:29:51 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mA4ATof9001693 for ; Tue, 04 Nov 2008 10:29:50 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K9T000010OSAN00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 04 Nov 2008 10:29:50 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K9T000ED15IPK90@fe-emea-10.sun.com>; Tue, 04 Nov 2008 10:29:42 +0000 (GMT) Date: Tue, 04 Nov 2008 10:29:42 +0000 From: Darren J Moffat Subject: Re: PSARC 2008/318 Boomer - potential issues In-reply-to: <490F46A2.6000102@Sun.COM> Sender: Darren.Moffat@Sun.COM To: Bart Smaalders Cc: "Garrett D'Amore" , PSARC-ext Message-id: <49102416.6000202@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <490F1BAC.1040001@sun.com> <490F46A2.6000102@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080922) Status: RO Content-Length: 1232 Bart Smaalders wrote: > Garrett D'Amore wrote: > >> 6) This seems to be leading us toward the road that we should, once OSS >> APIs become available everywhere, deprecate the use of Sun audio for >> mixer and control applications. > > > Your proposal seems to be a very reasonable approach for the > next Solaris release: continue to support application level use > (playback, record) of legacy Sun audio apis, but require use of > OSS interfaces for systemic control. > > Thanks for taking this on. I agreed too. One of the good and bad points about most UNIX based systems is the legacy and the multiple tools to achieve the same thing. Windows and MacOS X are IMO the real competitors in this area and because of their legacy they can pick a single mixer program and make that the supported way. I think we can safely do the same for OpenSolaris/Solaris.next by picking a single mixer API, ie OSS. As long as playback from SADA applications works I think that is sufficiently good enough. It isn't like the current situation with SADA apps and mixers is actually easy to understand or particularly useful anyway (especially on Sun Ray where it is just a nightmare of a user experience). -- Darren J Moffat From gdamore@sun.com Wed Jan 28 09:22:42 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0SHMggE004203 for ; Wed, 28 Jan 2009 09:22:42 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0SHMeaI026589 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 28 Jan 2009 09:22:42 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KE60094ZYXUO700@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Jan 2009 09:22:42 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KE6009O0YXKJZ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Jan 2009 09:22:32 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0SHMWOO011898 for ; Wed, 28 Jan 2009 09:22:32 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KE600501Y7OGY00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Jan 2009 09:22:32 -0800 (PST) Received: from [192.168.251.11] ([76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KE60094OYXKBR70@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Jan 2009 09:22:32 -0800 (PST) Date: Wed, 28 Jan 2009 09:22:31 -0800 From: "Garrett D'Amore" Subject: PSARC 2008/318 - Boomer: Next Generation Solaris Audio -- updates Sender: Garrett.Damore@sun.com To: PSARC-ext Message-id: <49809457.4020206@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 7365 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 From bart.smaalders@sun.com Wed Jan 28 11:38:10 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0SJcApa011186 for ; Wed, 28 Jan 2009 11:38:10 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0SJc6cp016589; Wed, 28 Jan 2009 12:38:09 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KE70031Z57IZ400@nwk-avmta-2.sfbay.sun.com>; Wed, 28 Jan 2009 11:38:06 -0800 (PST) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KE700L8U57IMLC0@nwk-avmta-2.sfbay.sun.com>; Wed, 28 Jan 2009 11:38:06 -0800 (PST) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id n0SJc6Pi000469; Wed, 28 Jan 2009 19:38:06 +0000 (GMT) Date: Wed, 28 Jan 2009 11:38:07 -0800 From: Bart Smaalders Subject: Re: PSARC 2008/318 - Boomer: Next Generation Solaris Audio -- updates In-reply-to: <49809457.4020206@sun.com> To: "Garrett D'Amore" Cc: PSARC-ext Message-id: <4980B41F.5060803@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49809457.4020206@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081216) Status: RO Content-Length: 478 Garrett D'Amore wrote: > Please let us know if there are any concerns about any of the above. > This looks good, Garrett. Can we also obsolete the ability to disable the mixer in mixerctl? I don't want to force all applications to have to deal with open calls to /dev/audio blocking indefinitely. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From gdamore@sun.com Wed Jan 28 11:47:17 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0SJlGCs011568 for ; Wed, 28 Jan 2009 11:47:17 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n0SJlATi016881 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 29 Jan 2009 03:47:15 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KE700J2L5MQVM00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Jan 2009 12:47:14 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KE700FNM5MPIS40@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Jan 2009 12:47:13 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0SJlCfQ018684 for ; Wed, 28 Jan 2009 11:47:12 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KE700J015DH6U00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Jan 2009 11:47:12 -0800 (PST) Received: from [192.168.251.11] ([76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KE700KY85MNBG90@fe-sfbay-10.sun.com>; Wed, 28 Jan 2009 11:47:11 -0800 (PST) Date: Wed, 28 Jan 2009 11:47:11 -0800 From: "Garrett D'Amore" Subject: Re: PSARC 2008/318 - Boomer: Next Generation Solaris Audio -- updates In-reply-to: <4980B41F.5060803@Sun.COM> Sender: Garrett.Damore@sun.com To: Bart Smaalders Cc: PSARC-ext Message-id: <4980B63F.6070807@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49809457.4020206@sun.com> <4980B41F.5060803@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 808 Bart Smaalders wrote: > Garrett D'Amore wrote: >> Please let us know if there are any concerns about any of the above. >> > > > This looks good, Garrett. Can we also obsolete the ability to > disable the mixer in mixerctl? I don't want to force all applications > to have to deal with open calls to /dev/audio blocking indefinitely. Yes, I'm sorry -- I thought I had already indicated this in the inception materials. It is not possible to disable the mixer. All support for any kind of "exclusive mode" access was removed in the Boomer gate a long time ago. :-) I suppose there might be certain *ancient* applications this breaks... but such applications would not have played well with other uses of the audio device anyway (include any use by desktop environments like gnome!) -- Garrett From gdamore@sun.com Wed Jan 28 13:33:00 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0SLX0A3002480 for ; Wed, 28 Jan 2009 13:33:00 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0SLWvfa009174 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 28 Jan 2009 21:32:59 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KE700H0DAIXJQ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Jan 2009 13:32:57 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KE700FCOAIXBM10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Jan 2009 13:32:57 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0SLWvS5015810 for ; Wed, 28 Jan 2009 13:32:57 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KE7000018I4A900@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Jan 2009 13:32:57 -0800 (PST) Received: from [192.168.251.11] ([76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KE700MCZAIG9F00@fe-sfbay-09.sun.com>; Wed, 28 Jan 2009 13:32:40 -0800 (PST) Date: Wed, 28 Jan 2009 13:32:40 -0800 From: "Garrett D'Amore" Subject: Re: PSARC 2008/318 - Boomer: Next Generation Solaris Audio -- updates In-reply-to: <4980B63F.6070807@sun.com> Sender: Garrett.Damore@sun.com To: Bart Smaalders Cc: PSARC-ext Message-id: <4980CEF8.3040508@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_/FTityrC6c8NSHH4MUl21w)" X-PMX-Version: 5.4.1.325704 References: <49809457.4020206@sun.com> <4980B41F.5060803@Sun.COM> <4980B63F.6070807@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 16092 This is a multi-part message in MIME format. --Boundary_(ID_/FTityrC6c8NSHH4MUl21w) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Garrett D'Amore wrote: > Bart Smaalders wrote: >> Garrett D'Amore wrote: >>> Please let us know if there are any concerns about any of the above. >>> >> >> >> This looks good, Garrett. Can we also obsolete the ability to >> disable the mixer in mixerctl? I don't want to force all applications >> to have to deal with open calls to /dev/audio blocking indefinitely. > > Yes, I'm sorry -- I thought I had already indicated this in the > inception materials. It is not possible to disable the mixer. All > support for any kind of "exclusive mode" access was removed in the > Boomer gate a long time ago. :-) > > I suppose there might be certain *ancient* applications this breaks... > but such applications would not have played well with other uses of > the audio device anyway (include any use by desktop environments like > gnome!) > > -- Garrett > > A few more notes on this topic: mixerctl has other changes: -e is silently ignored (and no longer documented) -i has very slightly different output (the format was never documented) -o returns a failure (you can't disable the mixer!) -v no longer dumps a meaningful audio_info structure -- this structure was intrinsic to SADA, and doesn't work well with OSS. The -v flag still means "verbose", but the details are quite different. When used by itself or with -i, no additional output is given: gdamore@tabasco{27}> mixerctl -iv Device: /dev/sound/0mixer Name = audio810#0 Config = NVIDIA AC'97 (CK804) HW Info = AC'97 codec: Avance Logic ALC655 And when used with new options, it tells you more about it. For example, with -c volume to query information about the volume control: gdamore@tabasco{30}> mixerctl -c volume DEVICE CONTROL VALUE POSSIBLE audio810#0 volume 75 0-100 gdamore@tabasco{32}> mixerctl -v -c volume Device: /dev/sound/0mixer Name = audio810#0 Config = NVIDIA AC'97 (CK804) HW Info = AC'97 codec: Avance Logic ALC655 CONTROL VALUE TYPE POSSIBLE volume 75 mono 0-100 With -C (dump all controls) it will show lots of information about each control: gdamore@tabasco{33}> mixerctl -v -C Device: /dev/sound/sndstat Name = audio#0 Config = Audio Common Code (pseudo) CONTROL VALUE TYPE POSSIBLE Device: /dev/sound/0mixer Name = audio810#0 Config = NVIDIA AC'97 (CK804) HW Info = AC'97 codec: Avance Logic ALC655 CONTROL VALUE TYPE POSSIBLE volume 75 mono 0-100 front 75:75 stereo 0-100:0-100 surround 75:75 stereo 0-100:0-100 center 75 mono 0-100 lfe 75 mono 0-100 record-gain 18:12 stereo 0-100:0-100 mic 0:0 stereo 0-100:0-100 line-in 0:0 stereo 0-100:0-100 cd 0:0 stereo 0-100:0-100 aux1-in 0:0 stereo 0-100:0-100 phone 0 mono 0-100 beep 75 mono 0-100 micboost off boolean on,off loopback off boolean on,off record-source mic enum mic,cd,aux1-in line-in,stereo-mix mono-mix,phone mic-source mic1 enum mic1,mic2 jack1 line-in enum line-in,surround jack2 mic enum mic,center/lfe And, when used with -c -w , it shows the effect being changed: gdamore@tabasco{34}> mixerctl -v -c volume -w 50 audio810#0: 'volume' set to '50' The fact is, that dumping the audio_info_t structure, while documented, was unlikely to have ever been particularly useful to anyone. We believe that the new output formats are far more useful, and somewhat in line with other commands like dladm. (And yes, we're working on a "parseable" version of the above formats, as well. That work is still not complete yet.) -- Garrett --Boundary_(ID_/FTityrC6c8NSHH4MUl21w) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Garrett D'Amore wrote:
Bart Smaalders wrote:
Garrett D'Amore wrote:
Please let us know if there are any concerns about any of the above.



This looks good, Garrett.  Can we also obsolete the ability to
disable the mixer in mixerctl?  I don't want to force all applications
to have to deal with open calls to /dev/audio blocking indefinitely.

Yes, I'm sorry -- I thought I had already indicated this in the inception materials.  It is not possible to disable the mixer.  All support for any kind of "exclusive mode" access was removed in the Boomer gate a long time ago. :-)

I suppose there might be certain *ancient* applications this breaks... but such applications would not have played well with other uses of the audio device anyway (include any use by desktop environments like gnome!)

   -- Garrett


A few more notes on this topic:

mixerctl has other changes:

-e is silently ignored (and no longer documented)
-i has very slightly different output (the format was never documented)
-o returns a failure (you can't disable the mixer!)
-v no longer dumps a meaningful audio_info structure -- this structure was intrinsic to SADA, and doesn't work well with OSS.  The -v flag still means "verbose", but the details are quite different.  When used by itself or with -i, no additional output is given:

gdamore@tabasco{27}> mixerctl -iv
Device: /dev/sound/0mixer
  Name    = audio810#0
  Config  = NVIDIA AC'97 (CK804)
  HW Info = AC'97 codec: Avance Logic ALC655

And when used with new options, it tells you more about it.  For example, with -c volume to query information about the volume control:

gdamore@tabasco{30}> mixerctl -c volume
DEVICE           CONTROL                  VALUE      POSSIBLE           
audio810#0       volume                   75         0-100              

gdamore@tabasco{32}> mixerctl -v -c volume
Device: /dev/sound/0mixer
  Name    = audio810#0
  Config  = NVIDIA AC'97 (CK804)
  HW Info = AC'97 codec: Avance Logic ALC655

CONTROL                  VALUE      TYPE     POSSIBLE           
volume                   75         mono     0-100              

With -C (dump all controls) it will show lots of information about each control:

gdamore@tabasco{33}> mixerctl -v -C
Device: /dev/sound/sndstat
  Name    = audio#0
  Config  = Audio Common Code (pseudo)

CONTROL                  VALUE      TYPE     POSSIBLE           

Device: /dev/sound/0mixer
  Name    = audio810#0
  Config  = NVIDIA AC'97 (CK804)
  HW Info = AC'97 codec: Avance Logic ALC655

CONTROL                  VALUE      TYPE     POSSIBLE           
volume                   75         mono     0-100              
front                    75:75      stereo   0-100:0-100        
surround                 75:75      stereo   0-100:0-100        
center                   75         mono     0-100              
lfe                      75         mono     0-100              
record-gain              18:12      stereo   0-100:0-100        
mic                      0:0        stereo   0-100:0-100        
line-in                  0:0        stereo   0-100:0-100        
cd                       0:0        stereo   0-100:0-100        
aux1-in                  0:0        stereo   0-100:0-100        
phone                    0          mono     0-100              
beep                     75         mono     0-100              
micboost                 off        boolean  on,off             
loopback                 off        boolean  on,off             
record-source            mic        enum     mic,cd,aux1-in     
                                             line-in,stereo-mix 
                                             mono-mix,phone     
mic-source               mic1       enum     mic1,mic2          
jack1                    line-in    enum     line-in,surround   
jack2                    mic        enum     mic,center/lfe     

And, when used with -c <control>  -w <value>, it shows the effect being changed:

gdamore@tabasco{34}> mixerctl -v -c volume -w 50
audio810#0: 'volume' set to '50'
The fact is, that dumping the audio_info_t structure, while documented, was unlikely to have ever been particularly useful to anyone.  We believe that the new output formats are far more useful, and somewhat in line with other commands like dladm.  (And yes, we're working on a "parseable" version of the above formats, as well.  That work is still not complete yet.)

    -- Garrett

--Boundary_(ID_/FTityrC6c8NSHH4MUl21w)-- From brian.utterback@sun.com Thu Jan 29 12:28:05 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0TKS4gl018474 for ; Thu, 29 Jan 2009 12:28:04 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0TKS2Jd023908; Thu, 29 Jan 2009 13:28:03 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KE90060J26QD200@nwk-avmta-2.sfbay.sun.com>; Thu, 29 Jan 2009 12:28:02 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KE90064A26O9N00@nwk-avmta-2.sfbay.sun.com>; Thu, 29 Jan 2009 12:28:00 -0800 (PST) Received: from [129.148.9.177] (sr1-ubur-23.East.Sun.COM [129.148.9.177]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0TKRvHc003068; Thu, 29 Jan 2009 15:27:58 -0500 (EST) Date: Thu, 29 Jan 2009 15:27:57 -0500 From: Brian Utterback Subject: Re: PSARC 2008/318 - Boomer: Next Generation Solaris Audio -- updates In-reply-to: <4980B63F.6070807@sun.com> To: "Garrett D'Amore" Cc: Bart Smaalders , PSARC-ext Message-id: <4982114D.9050502@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49809457.4020206@sun.com> <4980B41F.5060803@Sun.COM> <4980B63F.6070807@sun.com> User-Agent: Thunderbird 2.0.0.20pre (X11/20090108) Status: RO Content-Length: 2246 I have a concern about this. As part of NTP version 4, there is support for decoding the audio signal from the radio station WWV to provide a fairly accurate reference clock. The code currently hard codes the use of /dev/audio, but the NTP project has been very good about incorporating code changes. However, it sounds like you are saying that in the post Boomer world, there will be no way to access the audio device directly without going through the mixer, right? Of course, this is audio input, so maybe that doesn't apply. Using the mixer will likely make the WWV refclock useless. It is essential that the latency between the time that the signal reaches the hardware and the time that the audio arrives in the ntpd daemon's buffer be as small as possible. Failing that, the delays must be consistent and without jitter. Is this going to be a problem post Boomer? Garrett D'Amore wrote: > Bart Smaalders wrote: >> Garrett D'Amore wrote: >>> Please let us know if there are any concerns about any of the above. >>> >> >> >> This looks good, Garrett. Can we also obsolete the ability to >> disable the mixer in mixerctl? I don't want to force all applications >> to have to deal with open calls to /dev/audio blocking indefinitely. > > Yes, I'm sorry -- I thought I had already indicated this in the > inception materials. It is not possible to disable the mixer. All > support for any kind of "exclusive mode" access was removed in the > Boomer gate a long time ago. :-) > > I suppose there might be certain *ancient* applications this breaks... > but such applications would not have played well with other uses of the > audio device anyway (include any use by desktop environments like gnome!) > > -- Garrett > -- blu "Murderous organizations have increased in size and scope; they are more daring, they are served by the most terrible weapons offered by modern science, and the world is nowadays threatened by new forces which, if recklessly unchained, may some day wreak universal destruction." - Arthur Griffith, 1898 ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From gdamore@sun.com Thu Jan 29 14:45:13 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0TMjD4l022701 for ; Thu, 29 Jan 2009 14:45:13 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0TMjA1Z035602 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 29 Jan 2009 15:45:12 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KE900E1R8JBPG00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 14:45:11 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KE9006WL8JA9F90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 14:45:10 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0TMjAgX011060 for ; Thu, 29 Jan 2009 14:45:10 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KE900I018DPBM00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 14:45:10 -0800 (PST) Received: from [192.168.251.11] ([76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KE900LG98JA03E0@fe-sfbay-10.sun.com>; Thu, 29 Jan 2009 14:45:10 -0800 (PST) Date: Thu, 29 Jan 2009 14:45:09 -0800 From: "Garrett D'Amore" Subject: Re: PSARC 2008/318 - Boomer: Next Generation Solaris Audio -- updates In-reply-to: <4982114D.9050502@sun.com> Sender: Garrett.Damore@sun.com To: Brian Utterback Cc: Bart Smaalders , PSARC-ext Message-id: <49823175.6030105@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49809457.4020206@sun.com> <4980B41F.5060803@Sun.COM> <4980B63F.6070807@sun.com> <4982114D.9050502@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2604 Brian Utterback wrote: > I have a concern about this. As part of NTP version 4, there is > support for decoding the audio signal from the radio station WWV to > provide a fairly accurate reference clock. The code currently hard > codes the use of /dev/audio, but the NTP project has been very good > about incorporating code changes. However, it sounds like you are > saying that in the post Boomer world, there will be no way to access > the audio device directly without going through the mixer, right? > > Of course, this is audio input, so maybe that doesn't apply. Using the > mixer will likely make the WWV refclock useless. It is essential that > the latency between the time that the signal reaches the hardware and > the time that the audio arrives in the ntpd daemon's buffer be as > small as possible. Failing that, the delays must be consistent and > without jitter. Is this going to be a problem post Boomer? There should be very little jitter. The delays themselves are dependent on a few things: 1) the time from when the audio device receives the data until it interrupts us (at about 175 Hz, ~5-6 ms delay) 2) buffering done by the framework (currently 8K, and not tunable, but I'll fix that this week) as requested by application 3) the amount of data in STREAMS queues above the application I hadn't perceived a need for a smaller record buffer size than 8K, but I know understand why there would be. I'll make it tunable -- it won't be very hard to do. At the end of the day, we should be able to support NTP. Can you help with testing/validation of Boomer with NTP in this capacity? (I don't have the WWV equipment or expertise to test this myself.) -- Garrett > > Garrett D'Amore wrote: >> Bart Smaalders wrote: >>> Garrett D'Amore wrote: >>>> Please let us know if there are any concerns about any of the above. >>>> >>> >>> >>> This looks good, Garrett. Can we also obsolete the ability to >>> disable the mixer in mixerctl? I don't want to force all applications >>> to have to deal with open calls to /dev/audio blocking indefinitely. >> >> Yes, I'm sorry -- I thought I had already indicated this in the >> inception materials. It is not possible to disable the mixer. All >> support for any kind of "exclusive mode" access was removed in the >> Boomer gate a long time ago. :-) >> >> I suppose there might be certain *ancient* applications this >> breaks... but such applications would not have played well with other >> uses of the audio device anyway (include any use by desktop >> environments like gnome!) >> >> -- Garrett >> > From gdamore@sun.com Thu Jan 29 14:54:15 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0TMsFLI023198 for ; Thu, 29 Jan 2009 14:54:15 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0TMs9mr039832 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 29 Jan 2009 15:54:15 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KE900F018YE8R00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 14:54:14 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KE9006FY8YE9AB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 14:54:14 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0TMsEjS012005 for ; Thu, 29 Jan 2009 14:54:14 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KE9003018NB2G00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Jan 2009 14:54:14 -0800 (PST) Received: from [192.168.251.11] ([76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KE9004XV8YC6W20@fe-sfbay-10.sun.com>; Thu, 29 Jan 2009 14:54:12 -0800 (PST) Date: Thu, 29 Jan 2009 14:54:12 -0800 From: "Garrett D'Amore" Subject: Re: PSARC 2008/318 - Boomer: Next Generation Solaris Audio -- updates In-reply-to: <49823175.6030105@sun.com> Sender: Garrett.Damore@sun.com To: Brian Utterback Cc: Bart Smaalders , PSARC-ext Message-id: <49823394.1020106@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49809457.4020206@sun.com> <4980B41F.5060803@Sun.COM> <4980B63F.6070807@sun.com> <4982114D.9050502@sun.com> <49823175.6030105@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2887 Garrett D'Amore wrote: > Brian Utterback wrote: >> I have a concern about this. As part of NTP version 4, there is >> support for decoding the audio signal from the radio station WWV to >> provide a fairly accurate reference clock. The code currently hard >> codes the use of /dev/audio, but the NTP project has been very good >> about incorporating code changes. However, it sounds like you are >> saying that in the post Boomer world, there will be no way to access >> the audio device directly without going through the mixer, right? >> >> Of course, this is audio input, so maybe that doesn't apply. Using >> the mixer will likely make the WWV refclock useless. It is essential >> that the latency between the time that the signal reaches the >> hardware and the time that the audio arrives in the ntpd daemon's >> buffer be as small as possible. Failing that, the delays must be >> consistent and without jitter. Is this going to be a problem post >> Boomer? > > There should be very little jitter. > > The delays themselves are dependent on a few things: > > 1) the time from when the audio device receives the data until it > interrupts us (at about 175 Hz, ~5-6 ms delay) > 2) buffering done by the framework (currently 8K, and not tunable, but > I'll fix that this week) as requested by application > 3) the amount of data in STREAMS queues above the application > > I hadn't perceived a need for a smaller record buffer size than 8K, > but I know understand why there would be. I'll make it tunable -- it > won't be very hard to do. Btw, it will be possible for applications to request *no* buffering of record data be performed. In which case we'll send it up as soon as we've got it. :-) -- Garrett > > At the end of the day, we should be able to support NTP. > > Can you help with testing/validation of Boomer with NTP in this > capacity? (I don't have the WWV equipment or expertise to test this > myself.) > > -- Garrett >> >> Garrett D'Amore wrote: >>> Bart Smaalders wrote: >>>> Garrett D'Amore wrote: >>>>> Please let us know if there are any concerns about any of the above. >>>>> >>>> >>>> >>>> This looks good, Garrett. Can we also obsolete the ability to >>>> disable the mixer in mixerctl? I don't want to force all applications >>>> to have to deal with open calls to /dev/audio blocking indefinitely. >>> >>> Yes, I'm sorry -- I thought I had already indicated this in the >>> inception materials. It is not possible to disable the mixer. All >>> support for any kind of "exclusive mode" access was removed in the >>> Boomer gate a long time ago. :-) >>> >>> I suppose there might be certain *ancient* applications this >>> breaks... but such applications would not have played well with >>> other uses of the audio device anyway (include any use by desktop >>> environments like gnome!) >>> >>> -- Garrett >>> >> > From brian.utterback@sun.com Fri Jan 30 06:13:37 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0UEDb9V021272 for ; Fri, 30 Jan 2009 06:13:37 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0UEDU44020354; Fri, 30 Jan 2009 14:13:35 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEA0081DFIK1000@nwk-avmta-2.sfbay.sun.com>; Fri, 30 Jan 2009 06:13:32 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEA00KOBFIJA7B0@nwk-avmta-2.sfbay.sun.com>; Fri, 30 Jan 2009 06:13:31 -0800 (PST) Received: from [129.148.9.177] (sr1-ubur-23.East.Sun.COM [129.148.9.177]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n0UEDSbZ001150; Fri, 30 Jan 2009 09:13:29 -0500 (EST) Date: Fri, 30 Jan 2009 09:13:28 -0500 From: Brian Utterback Subject: Re: PSARC 2008/318 - Boomer: Next Generation Solaris Audio -- updates In-reply-to: <49823394.1020106@sun.com> To: "Garrett D'Amore" Cc: Bart Smaalders , PSARC-ext Message-id: <49830B08.3070304@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49809457.4020206@sun.com> <4980B41F.5060803@Sun.COM> <4980B63F.6070807@sun.com> <4982114D.9050502@sun.com> <49823175.6030105@sun.com> <49823394.1020106@sun.com> User-Agent: Thunderbird 2.0.0.20pre (X11/20090108) Status: RO Content-Length: 3968 That's great. Alas, I can't help with the testing, since I am in New Hampshire and the only shortwave radio available to me was unable to pick up either WWV or WWVB. If there is anybody in Broomfield that can give it a try, I would appreciate it. People in Broomfield ought to be able to pick up WWV on their fillings. 8-) Or if there is anybody in the Burlington area with a better Shortwave that I could tap into the audio signal for a little while, that would work too. Garrett D'Amore wrote: > Garrett D'Amore wrote: >> Brian Utterback wrote: >>> I have a concern about this. As part of NTP version 4, there is >>> support for decoding the audio signal from the radio station WWV to >>> provide a fairly accurate reference clock. The code currently hard >>> codes the use of /dev/audio, but the NTP project has been very good >>> about incorporating code changes. However, it sounds like you are >>> saying that in the post Boomer world, there will be no way to access >>> the audio device directly without going through the mixer, right? >>> >>> Of course, this is audio input, so maybe that doesn't apply. Using >>> the mixer will likely make the WWV refclock useless. It is essential >>> that the latency between the time that the signal reaches the >>> hardware and the time that the audio arrives in the ntpd daemon's >>> buffer be as small as possible. Failing that, the delays must be >>> consistent and without jitter. Is this going to be a problem post >>> Boomer? >> >> There should be very little jitter. >> >> The delays themselves are dependent on a few things: >> >> 1) the time from when the audio device receives the data until it >> interrupts us (at about 175 Hz, ~5-6 ms delay) >> 2) buffering done by the framework (currently 8K, and not tunable, but >> I'll fix that this week) as requested by application >> 3) the amount of data in STREAMS queues above the application >> >> I hadn't perceived a need for a smaller record buffer size than 8K, >> but I know understand why there would be. I'll make it tunable -- it >> won't be very hard to do. > > Btw, it will be possible for applications to request *no* buffering of > record data be performed. In which case we'll send it up as soon as > we've got it. :-) > > -- Garrett >> >> At the end of the day, we should be able to support NTP. >> >> Can you help with testing/validation of Boomer with NTP in this >> capacity? (I don't have the WWV equipment or expertise to test this >> myself.) >> >> -- Garrett >>> >>> Garrett D'Amore wrote: >>>> Bart Smaalders wrote: >>>>> Garrett D'Amore wrote: >>>>>> Please let us know if there are any concerns about any of the above. >>>>>> >>>>> >>>>> >>>>> This looks good, Garrett. Can we also obsolete the ability to >>>>> disable the mixer in mixerctl? I don't want to force all applications >>>>> to have to deal with open calls to /dev/audio blocking indefinitely. >>>> >>>> Yes, I'm sorry -- I thought I had already indicated this in the >>>> inception materials. It is not possible to disable the mixer. All >>>> support for any kind of "exclusive mode" access was removed in the >>>> Boomer gate a long time ago. :-) >>>> >>>> I suppose there might be certain *ancient* applications this >>>> breaks... but such applications would not have played well with >>>> other uses of the audio device anyway (include any use by desktop >>>> environments like gnome!) >>>> >>>> -- Garrett >>>> >>> >> > -- blu "Murderous organizations have increased in size and scope; they are more daring, they are served by the most terrible weapons offered by modern science, and the world is nowadays threatened by new forces which, if recklessly unchained, may some day wreak universal destruction." - Arthur Griffith, 1898 ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From carlsonj@phorcys.east.sun.com Fri Jan 30 07:06:02 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n0UF62GG022301 for ; Fri, 30 Jan 2009 07:06:02 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n0UF5v7o027924; Fri, 30 Jan 2009 07:06:00 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEA0024BHY01B00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 30 Jan 2009 07:06:00 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEA00I5CHXYSA70@nwk-avmta-1.sfbay.Sun.COM>; Fri, 30 Jan 2009 07:05:58 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n0UF5tlq020757; Fri, 30 Jan 2009 10:05:55 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n0UF5tZV020754; Fri, 30 Jan 2009 10:05:55 -0500 (EST) Date: Fri, 30 Jan 2009 10:05:55 -0500 From: James Carlson Subject: Re: PSARC 2008/318 - Boomer: Next Generation Solaris Audio -- updates In-reply-to: <49830B08.3070304@sun.com> To: Brian Utterback Cc: "Garrett D'Amore" , PSARC-ext , Bart Smaalders Message-id: <18819.5971.881776.582298@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49809457.4020206@sun.com> <4980B41F.5060803@Sun.COM> <4980B63F.6070807@sun.com> <4982114D.9050502@sun.com> <49823175.6030105@sun.com> <49823394.1020106@sun.com> <49830B08.3070304@sun.com> Status: RO Content-Length: 893 Brian Utterback writes: > That's great. Alas, I can't help with the testing, since I am in New > Hampshire and the only shortwave radio available to me was unable to > pick up either WWV or WWVB. If there is anybody in Broomfield that can > give it a try, I would appreciate it. People in Broomfield ought to be > able to pick up WWV on their fillings. 8-) Or if there is anybody in > the Burlington area with a better Shortwave that I could tap into the > audio signal for a little while, that would work too. I'm listening to WWV on 15MHz right now. Not the greatest signal, but it works ok with just a length of wire. I can probably lend you the receiver. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From gdamore@sun.com Fri Feb 13 00:00:11 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1D80AHG012157 for ; Fri, 13 Feb 2009 00:00:10 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1D7xl2o006143; Fri, 13 Feb 2009 08:00:09 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KEZ0090NVK4US00@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Feb 2009 00:00:04 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEZ008NWVK34M20@nwk-avmta-2.sfbay.sun.com>; Fri, 13 Feb 2009 00:00:03 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1D802RB020736; Fri, 13 Feb 2009 00:00:02 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KEZ00H00V74SM00@fe-sfbay-09.sun.com>; Fri, 13 Feb 2009 00:00:02 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KEZ004XYVK2DP60@fe-sfbay-09.sun.com>; Fri, 13 Feb 2009 00:00:02 -0800 (PST) Date: Fri, 13 Feb 2009 00:00:02 -0800 From: "Garrett D'Amore" Subject: PSARC 2008/318 Boomer -- update Sender: Garrett.Damore@sun.com To: PSARC-ext Cc: audio-ng-core@sun.com, steve.uhler@sun.com Message-id: <49952882.2010603@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2522 With the impending EOF of sdtaudiocontrol (LSARC 2009/074, times out 2/16/2009), I believe that there are no further applications which exist and make use of most of the ioctls spelled out in mixer(7i). Specifically, the following ioctls are in question: AUDIO_MIXERCTL_GET_MODE AUDIO_MIXERCTL_SET_MODE AUDIO_MIXERCTL_GET_CHINFO AUDIO_MIXERCTL_SET_CHINFO AUDIO_MIXERCTL_GETINFO AUDIO_MIXERCTL_SETINFO AUDIO_MIXER_MULTIPLE_OPEN* AUDIO_MIXER_SINGLE_OPEN additionally, the following ioctls in audio_support(7i) don't appear to be used by any other applications either: AUDIO_GET_NUM_CHS AUDIO_GET_CH_NUMBER AUDIO_GET_CH_TYPE * (AUDIO_MIXER_MULTIPLE_OPEN is called by some 3rd party code, but none of the code I've seen, including gstreamer, actually *relies* on it. All the code I've seen simply ignores the result code.) I'd like to eliminate these ioctls from the Boomer code base. There is a huge amount of complexity that these ioctls create, due largely to the poorly thought out way in which the mixer API was tacked onto the main audio API, as well as ambiguity in what some of them do. Furthermore, no applications that wanted to be reasonably portable could rely on them, since historically not all audio devices have supported the mixer API. (Sun Ray still doesn't support this API.) Such a clean up would eliminate many hundreds of lines of complex code, including the need for some rather Byzantine locking and synchronization that has to be done between streams. Note that I'm not proposing to eliminate the ability of multiple applications to use the audio device simultaneously. What instead I'm proposing to do is treat each process as if it had its own private device; that means that only one audio file (or two if one is read and the other is write) can be open at a time. Applications that want to do more sophisticated things with audio should really consider the OSS API. The OSS API is much saner in significant ways, and is free from the worst of the synchronization problems and ambiguity that plagues the mixer(7i) and audio(7i) APIs. (Plus, in Boomer, you have a lot more flexibility with other things.) If anyone has any significant objections to this, I'd like to hear them. Likewise if anyone knows any applications other than sdtaudiocontrol and mixerctl which use the above APIs, I'd like to know. (And yes, we'll be "fixing" mixerctl to not use the APIs in question as part of Boomer.) -- Garrett From Darren.Moffat@sun.com Fri Feb 13 04:38:02 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1DCc1I0022552 for ; Fri, 13 Feb 2009 04:38:01 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1DCbmdl026024; Fri, 13 Feb 2009 12:38:00 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KF000C0L8F9XA00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 13 Feb 2009 04:37:57 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KF000MA38F8NRA0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 13 Feb 2009 04:37:57 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1DCbu14009991; Fri, 13 Feb 2009 12:37:56 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KF00050086LLT00@fe-emea-09.sun.com>; Fri, 13 Feb 2009 12:37:56 +0000 (GMT) Received: from [129.156.173.199] ([unknown] [129.156.173.199]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KF000MGW8F7EU00@fe-emea-09.sun.com>; Fri, 13 Feb 2009 12:37:56 +0000 (GMT) Date: Fri, 13 Feb 2009 12:37:55 +0000 From: Darren J Moffat Subject: Re: PSARC 2008/318 Boomer -- update In-reply-to: <49952882.2010603@sun.com> Sender: Darren.Moffat@sun.com To: "Garrett D'Amore" Cc: PSARC-ext , audio-ng-core@sun.com, steve.uhler@sun.com Message-id: <499569A3.8020003@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49952882.2010603@sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081119) Status: RO Content-Length: 368 Garrett D'Amore wrote: > If anyone has any significant objections to this, I'd like to hear > them. Likewise if anyone knows any applications other than > sdtaudiocontrol and mixerctl which use the above APIs, I'd like to > know. (And yes, we'll be "fixing" mixerctl to not use the APIs in > question as part of Boomer.) Sounds fine to me. -- Darren J Moffat From gdamore@sun.com Mon Feb 16 23:21:43 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1H7LgPf020477 for ; Mon, 16 Feb 2009 23:21:43 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n1H7LbUt004889 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 17 Feb 2009 15:21:41 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KF700L038G34000@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 17 Feb 2009 00:21:39 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KF700EE38G25Z30@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 17 Feb 2009 00:21:39 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1H7LcUW028063 for ; Mon, 16 Feb 2009 23:21:38 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KF70000079QN900@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 16 Feb 2009 23:02:43 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KF700B337KI0R60@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 16 Feb 2009 23:02:43 -0800 (PST) Date: Mon, 16 Feb 2009 23:21:38 -0800 From: "Garrett D'Amore" Subject: PSARC 2008/318 Boomer - next gen Solaris audio - architecture update Sender: Garrett.Damore@sun.com To: PSARC-ext Message-id: <499A6582.4040007@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1806 I'll be posting updated materials in the first day or two. But there is one more change which I think deserves special notion. In order to facilitate greater fidelity in our implementation of the OSS APIs, we have converted the Boomer core to use normal character device interfaces for the OSS device nodes. Sun audio(7i) style nodes are still based on STREAMs. The astute will note that Solaris can't have both STREAMs nodes and character nodes on the same driver (you only get one cb_ops per driver.) The solution Boomer has taken to this problem is to use a thin-layer pseudo driver (austr) to provide the STREAMs minor nodes. Internally, LDI open & close are used to make sure the DDI reference counts are accurate, but all data transfer uses a fast & light weight function call mechanism, so there should not be any performance penalty. The reason for this change is to eliminate extra overhead & latency associated with STREAMs, and to eliminate ambiguity that was resulting from the fact that the OSS API has no way to express the details of the queuing that was being added by the STREAMs layer. Upshot of this is of course faster, lower overhead for OSS applications, and *much* more accurate reporting of latency and positioning details. (At the moment the accuracy of sample position reporting is limited only to two things: the accuracy of system clock and the physical device's ability to report its sampling position. Most devices have a 64-byte internal FIFO without any ability to introspect into them, so that will tend to be the approximate error for these devices. For a typical device running at 16-bit stereo 48kHz, that corresponds to an error of approximately 320 usec, which should be *plenty* accurate enough for reasonable uses.) -- Garrett From gdamore@sun.com Wed Feb 25 10:02:43 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1PI2guq011448 for ; Wed, 25 Feb 2009 10:02:43 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1PI2g3E021737 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 25 Feb 2009 10:02:42 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFM00027VGH9S00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Feb 2009 10:02:41 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFM00J94VGGJP50@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Feb 2009 10:02:40 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1PI2eB2000902 for ; Wed, 25 Feb 2009 10:02:40 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFM00100VA4DZ00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Feb 2009 10:02:40 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFM00BO8VGED5B0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Feb 2009 10:02:38 -0800 (PST) Date: Wed, 25 Feb 2009 10:02:38 -0800 From: "Garrett D'Amore" Subject: PSARC 2008/318 Boomer: Next Gen Solaris Audio Sender: Garrett.Damore@sun.com To: PSARC-ext Message-id: <49A587BE.3060701@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2984 I've posted commitment materials for this case. I still need to post an updated 20q file. I'll do that later today, but I think most of us already know what this project is about. The main file to read is the boomer.pdf file, which is the primary project specification. The rest of the documents are man pages which document the specific interfaces that are part of Boomer. dsp.7i and mixer.7i contain the details of the OSS API itself. Note that all the interfaces in the section 9 pages are Consolidation Private, and all the rest are Uncommitted or Obsolete Uncommitted. (Check the man pages for specific details.) -- Garrett gd78059@sac{21}> pwd /shared/sac/Archives/CaseLog/arc/PSARC/2008/318 gd78059@sac{22}> ls -la commitment.materials/ total 822 drwxr-sr-x 2 gd78059 sac 31 Feb 25 09:58 . drwxrwsr-x 9 gd78059 sac 13 Feb 25 09:52 .. -rw-r--r-- 1 gd78059 sac 7961 Feb 25 09:53 audio.7d -rw-r--r-- 1 gd78059 sac 32492 Feb 25 09:53 audio.7i -rw-r--r-- 1 gd78059 sac 6381 Feb 25 09:53 audio_dev_add_control.9f -rw-r--r-- 1 gd78059 sac 1509 Feb 25 09:53 audio_dev_add_engine.9f -rw-r--r-- 1 gd78059 sac 2322 Feb 25 09:53 audio_dev_alloc.9f -rw-r--r-- 1 gd78059 sac 1463 Feb 25 09:53 audio_dev_register.9f -rw-r--r-- 1 gd78059 sac 1412 Feb 25 09:53 audio_dev_set_description.9f -rw-r--r-- 1 gd78059 sac 866 Feb 25 09:53 audio_dev_set_private.9f -rw-r--r-- 1 gd78059 sac 791 Feb 25 09:53 audio_dev_warn.9f -rw-r--r-- 1 gd78059 sac 2018 Feb 25 09:53 audio_engine_alloc.9f -rw-r--r-- 1 gd78059 sac 1830 Feb 25 09:53 audio_engine_chinfo.9e -rw-r--r-- 1 gd78059 sac 1321 Feb 25 09:53 audio_engine_count.9e -rw-r--r-- 1 gd78059 sac 3942 Feb 25 09:53 audio_engine_open.9e -rw-r--r-- 1 gd78059 sac 2114 Feb 25 09:53 audio_engine_ops.9s -rw-r--r-- 1 gd78059 sac 1254 Feb 25 09:53 audio_engine_produce.9f -rw-r--r-- 1 gd78059 sac 707 Feb 25 09:53 audio_engine_qlen.9e -rw-r--r-- 1 gd78059 sac 1409 Feb 25 09:53 audio_engine_rates.9e -rw-r--r-- 1 gd78059 sac 1312 Feb 25 09:53 audio_engine_reset.9f -rw-r--r-- 1 gd78059 sac 1006 Feb 25 09:53 audio_engine_start.9e -rw-r--r-- 1 gd78059 sac 1248 Feb 25 09:53 audio_engine_sync.9e -rw-r--r-- 1 gd78059 sac 1323 Feb 25 09:53 audio_init_ops.9f -rw-r--r-- 1 gd78059 sac 23 Feb 25 09:53 audio_support.7i -rw-r--r-- 1 gd78059 sac 1953 Feb 25 09:53 audiocs.7d -rw-r--r-- 1 gd78059 sac 1303 Feb 25 09:53 audiopci.7d -rw-r--r-- 1 gd78059 sac 1095 Feb 25 09:53 austr.7d -rw-r--r-- 1 gd78059 sac 207004 Feb 25 09:52 boomer.pdf -rw-r--r-- 1 gd78059 sac 18714 Feb 25 09:53 dsp.7i -rw-r--r-- 1 gd78059 sac 20574 Feb 25 09:53 mixer.7i -rw-r--r-- 1 gd78059 sac 3372 Feb 25 09:58 mixerctl.1 From gdamore@sun.com Sat Feb 28 11:33:34 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1SJXX3K027952 for ; Sat, 28 Feb 2009 11:33:33 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n1SJXAGD018952 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 1 Mar 2009 03:33:32 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFS00C03JNUSO00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 28 Feb 2009 11:33:30 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFS005WRJNU1830@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 28 Feb 2009 11:33:30 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n1SJXUoj005629 for ; Sat, 28 Feb 2009 11:33:30 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFS00300JBN4P00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 28 Feb 2009 11:33:30 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFS00LD9JNTRLB0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 28 Feb 2009 11:33:30 -0800 (PST) Date: Sat, 28 Feb 2009 11:33:29 -0800 From: "Garrett D'Amore" Subject: PSARC 2008/318 Boomer: Next Gen Solaris Audio Sender: Garrett.Damore@sun.com To: opensound-discuss@opensolaris.org, PSARC-ext Message-id: <49A99189.9030802@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 410 Since the opensolaris infrastructure for the ARC community is having trouble getting my Boomer materials in the open, I've made another public copy of them available using a *different* piece of opensolaris infrastructure. ;-) You can access all of the Boomer commitment materials posted to date here: http://cr.opensolaris.org/~gdamore/boomer-commitment/ Thanks. Sorry for the hiccup. -- Garrett From garrett@damore.org Mon Mar 2 11:01:00 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n22J10Jo019801 for ; Mon, 2 Mar 2009 11:01:00 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n22J0qWp006251 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 2 Mar 2009 11:01:00 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KFW004137HNCK00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Mar 2009 12:00:59 -0700 (MST) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KFW001HQ7HLIP30@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 02 Mar 2009 12:00:57 -0700 (MST) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n22IipgF020756 for ; Mon, 02 Mar 2009 19:00:56 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay44i.sun.com with ESMTP id BT-MMP-839561 for PSARC-ext@sun.com; Mon, 02 Mar 2009 19:00:56 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-11857316 for PSARC-ext@sun.com; Mon, 02 Mar 2009 19:00:56 +0000 (Z) Received: from outbound-mail-19.bluehost.com ([69.89.20.234] [69.89.20.234]) by relay4i.sun.com id BT-MMP-11169689 for PSARC-ext@sun.com; Mon, 02 Mar 2009 19:00:56 +0000 (Z) Received: (qmail 15649 invoked by uid 0); Mon, 02 Mar 2009 18:59:19 +0000 Received: from unknown (HELO box374.bluehost.com) (69.89.31.174) by outboundproxy1.bluehost.com with SMTP; Mon, 02 Mar 2009 18:59:19 +0000 Received: from sca-ea-fw-1.sun.com ([192.18.43.225] helo=[10.7.251.172]) by box374.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LeDNb-0006K3-Gp for PSARC-ext@sun.com; Mon, 02 Mar 2009 12:00:43 -0700 Date: Mon, 02 Mar 2009 11:00:42 -0800 From: "Garrett D'Amore" Subject: PSARC 2008/318 Boomer: Next Gen Solaris Audio To: PSARC-ext Message-id: <49AC2CDA.9000803@damore.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=damore.org; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=iTAmcAyPENIR9pmYXrfGlh5lPr61SF32wzwv8PHFs184AgPHywurepMyXjBY5Os4iy2CEKJNr+qpk8J5KLtK80DDD6+7nQo88Sqt9aa4p6JuwPzLi8TCW6xPbwpKlkTT; X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Identified-User: {2225:box374.bluehost.com:damoreor:damore.org} {sentby:smtp auth 192.18.43.225 authed with garrett+damore.org} X-Antispam: No, score=0.0/5.0, scanned in 0.312sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1049 I've made some minor corrections to the dsp.7i manual page to reflect feedback received from 4Front. The file is posted here (with change bars): -rw-r--r-- 1 nobody nobody 17593 Mar 2 10:54 /net/sac.sfbay/export/sac/PSARC/2008/318/commitment.materials/dsp.7i The changes reflect: * open() of an OSS style dsp device always acts as non-blocking -- it returns EBUSY immediately if no channels are available, regardless of the presence or absence of FNDELAY or FNONBLOCK. * removed documentation of initial configuration -- applications must not depend on initial setup but explicitly configure it. * SNDCTL_DSP_SETTRIGGER and SNDCTL_DSP_GETTRIGGER ioctls are demoted to "compatibility use only" status (with no doc details). (They cannot be used to "pause" a stream.) * doc errors in the details of SNDCTL_DSP_SETFMT and SNDCTL_DSP_GETFMTS ioctl. * clarifications made for SNDCTL_DSP_SYNC. * added AFMT_xx_NE (native endian) formats. If anyone wants the actual diffs, let me know. -- Garrett From Phi.Tran@sun.com Wed Mar 4 13:17:18 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n24LHIlL007918 for ; Wed, 4 Mar 2009 13:17:18 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n24LHA04010851 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 4 Mar 2009 21:17:17 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KG00081334QY300@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 14:17:14 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KG000EMT34OHDC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 14:17:13 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n24LHC3W017535 for ; Wed, 04 Mar 2009 13:17:12 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KG000B002ZVB100@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 13:17:12 -0800 (PST) Received: from [10.6.46.117] ([unknown] [10.6.46.117]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KG000EHC34BYQ60@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Mar 2009 13:16:59 -0800 (PST) Date: Wed, 04 Mar 2009 13:16:26 -0800 From: Phi Tran Subject: Case Approved: PSARC 2008/318 Boomer: Next Gen Solaris Audio Sender: Phi.Tran@sun.com To: PSARC-ext@sun.com Cc: "Garrett D'Amore" Message-id: <49AEEFAA.1090306@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.17 (X11/20081119) Status: RO Content-Length: 117 This case was approved at today's PSARC meeting with one TCR and one TCA. The opinion will be coming out soon. Phi From Phi.Tran@sun.com Thu Mar 5 15:39:44 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n25Ndi9L004343 for ; Thu, 5 Mar 2009 15:39:44 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n25NdfDf001017 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 5 Mar 2009 15:39:44 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KG2006274E75A00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 05 Mar 2009 16:39:43 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KG200BCZ4E5LDD0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 05 Mar 2009 16:39:42 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n25NdfOf029767 for ; Thu, 05 Mar 2009 15:39:41 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KG200M0043AYS00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 05 Mar 2009 15:39:41 -0800 (PST) Received: from [10.6.46.217] ([unknown] [10.6.46.217]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KG200LJM4E4QP30@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 05 Mar 2009 15:39:40 -0800 (PST) Date: Thu, 05 Mar 2009 15:39:06 -0800 From: Phi Tran Subject: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio Sender: Phi.Tran@sun.com To: PSARC-ext@sun.com Message-id: <49B0629A.8000900@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Ro0GwGyEvR0/pfRY+xBjOw)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.17 (X11/20081119) Status: RO Content-Length: 8803 This is a multi-part message in MIME format. --Boundary_(ID_Ro0GwGyEvR0/pfRY+xBjOw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Please review the attached draft opinion by Fri 3/13/09. Thanks. Phi --Boundary_(ID_Ro0GwGyEvR0/pfRY+xBjOw) Content-type: text/plain; name=opinion.ascii Content-transfer-encoding: 7BIT Content-disposition: inline; filename=opinion.ascii sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Boomer: Next Generation Audio Submitted by: Garrett D'Amore File: PSARC/2008/318/opinion.ascii Date: March 5th, 2009 Committee: Garrett D'Amore (opinion written by Phi Tran), James D. Carlson, Mark Carlson, Ricky Matthews, Sebastien Roy, Glen Skinner. Abstain: Gary Winiger Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary Boomer: Next Generation Audio is a project to modernize the Solaris kernel-based audio system. The framework will be modernized to support the popular Open Sound System API used by several popular free operating systems, including Linux and FreeBSD. Audio quality will be improved by adding features such as high definition (both high frequency and high resolution sampling) and multichannel (for example, 7.1 surround sound) audio support. 2. Decision & Precedence Information The project is approved as specified in reference [1] - [3], but as modified by the required technical change listed in Appendix A and B below. The project may be delivered in a minor release of the ON consolidation. The project depends on the following other project and may not be delivered before it. LSARC/2009/074 EOF sdtaudiocontrol 3. Interfaces The project exports the following interfaces. ___ ___________________________________________________________________________ | Interfaces Exported | |_____________________________________________________________________________| |Interface Name | Classification | Comment | |______________________|_______________________ |_____________________________| |audio(7I) | Obsolete Committed | We've marked this API as | | | | Obsolete. We've also | | | | changed some semantics in | | | | ways that we believe are | | | | compatible. | | | | See the specification | | | | for more detail. | |mixer(7I) | See comments. | The old Sun mixer(7I) has | | | | been REMOVED. A new OSSv4 | | | | API is provided in its | | | | place with Uncommitted | | | | binding. | | | | See the specification for | | | | more detail. | |OSS API | Uncommitted | External userland API spec.| |/dev/sndstat | Uncommitted | Node for finding OSS dev | | | | nodes. | |/dev/audio | Obsolete Committed | Legacy Sun | |/dev/audioctl | Obsolete Committed | Legacy Sun | |/dev/sound/[0-9]+ | Obsolete Committed | Legacy Sun | |/dev/sound/[0-9]+ctl | Obsolete Committed | Legacy Sun | |/dev/mixer | Uncommitted | Symbolic link to | | | | /dev/sndstat | |/dev/dsp | Uncommitted | File name may change. | |Boomer DDI | Consolidation Private | New device driver API | |ac97 DDI | Consolidation Private | AC'97 support routines. | |SADA DDI | REMOVED | Legacy device driver API | |amsrc2 | REMOVED | | |mixer(7d) | REMOVED | | |audiosup(7d) | REMOVED | | |mixerctl(1) | Uncommitted | New CLI switches, may raise| | | | commitment later. | |audio control names | Uncommitted | ASCIIZ representation for | | | | hardware audio controls. | |audioplay -p & -m | REMOVED | Per TCA | |audiorecord -p & -m | REMOVED | Per TCA | |Client Personality API| Project Private | "audio_client.h" header. | |audiopci | Uncommitted | New audio driver. | |______________________|________________________|_____________________________| The project imports the following interfaces. ______________________________________________________________________________ | Interfaces Imported | |______________________|________________________|_____________________________| |Interface Name | Classification | Comments | |______________________|________________________|_____________________________| |OSS API | Uncommitted | We implement this API, but | | | | it is an external | | | | specification. | |audio(7I) | Obsoleted Committed | We implement these APIs | |______________________|________________________|_____________________________| 4. Opinion 4.1 sdtaudiocontrol dependency A member wanted to understand if sdtaudiocontrol should be removed from Nevada before Boomer integration. The project team noted that LSARC/2009/074 EOF sdtaudiocontrol has been filed. In addition, LSARC/2009/074 is noted as a dependency for this case and the project team will file a bug. 4.2 digital telephone interface support A member questioned if Boomer could architecturally support digital telephone interfaces which are inherently 8-bit mu-law PCM (or A-law in Europe). The project team clarified that there is no support currently in Boomer to handle telephone inputs, but that Boomer could support these interfaces if there was a need. 4.3 audioplay and audiorecord command line options A member asked if the disabled command line options in audioplay and audiorecord will have an EOF announcement. Other members stated that having the functionality of the command line options available and not work properly was problematic. The project team noted that these command line options were still available due to concern over breaking programs that depend on them. The project team decided that this concern was not a strong enough reason and agreed to a TCR to make the EOF announcement regarding the command line options. Also, the project team agreed to a TCA to remove disabled command line options that handle port selection and master settings such as volume control and monitor gain. 4.4 audigy and SADA DDI Since the audigy driver will not be supported in phase I, a member asked about the support of the public SADA interfaces. The project team clarified that the SADA interfaces are actually consolidation private and not public. 5. Minority Opinion(s) None. 6. Advisory Information None. 7. Appendices 7.1. Appendix A: Technical Changes Required 1. The project team will make an EOF announcement about disabled audioplay and audiorecord command line options. 7.2. Appendix B: Technical Changes Advised 1. The project team will remove disabled command line options that handle port selection and master settings such as volume control and monitor gain. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2008/318. 1, 20 Questions File: inception.materials/boomer.20q 2. Project Specification File: commitment.materials/boomer.pdf 3. Issues and Responses File: issues 4. Man Page for dsp OSS API File: commitment.materials/dsp.7I 5. Man Page for mixer OSS API File: commitment.materials/mixer.7I 6. Community OSS website http://developer.opensound.com/ --Boundary_(ID_Ro0GwGyEvR0/pfRY+xBjOw)-- From sac-owner Mon Mar 16 15:07:23 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2GM7MVi005485 for ; Mon, 16 Mar 2009 15:07:22 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2GM7MXq027395 for <@sunmail2sca.sfbay.sun.com:sac-review@sun.com>; Mon, 16 Mar 2009 16:07:22 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KGM00707DGAYS00@brm-avmta-1.central.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Mon, 16 Mar 2009 16:07:22 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KGM003I0DG9JL60@brm-avmta-1.central.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Mon, 16 Mar 2009 16:07:21 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2GM7KlC002888 for ; Mon, 16 Mar 2009 15:07:20 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KGM00400CWMGU00@fe-sfbay-10.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Mon, 16 Mar 2009 15:07:20 -0700 (PDT) Received: from [10.6.46.217] ([unknown] [10.6.46.217]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KGM007RRDG8IIA0@fe-sfbay-10.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Mon, 16 Mar 2009 15:07:20 -0700 (PDT) Date: Mon, 16 Mar 2009 15:06:41 -0700 From: Phi Tran Subject: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio Sender: Phi.Tran@sun.com To: sac-review@sun.com Message-id: <49BECD71.8020905@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_zFAAoM67rZp6Pf6zTa3lZg)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.17 (X11/20081119) Status: RO Content-Length: 9192 This is a multi-part message in MIME format. --Boundary_(ID_zFAAoM67rZp6Pf6zTa3lZg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Please review the attached opinion by Mon 3/23/09. Thanks. Phi --Boundary_(ID_zFAAoM67rZp6Pf6zTa3lZg) Content-type: text/plain; name=opinion.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=opinion.txt sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Boomer: Next Generation Audio Submitted by: Garrett D'Amore File: PSARC/2008/318/opinion.ms Date: March 5th, 2009 Committee: Garrett D'Amore (opinion written by Phi Tran), James D. Carlson, Mark Carlson, Rick Matthews, Sebastien Roy, Glenn Skinner. Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary Boomer: Next Generation Audio is a project to modernize the Solaris kernel-based audio system. The framework will be modernized to support the popular Open Sound System API used by several popular free operating systems, including Linux and FreeBSD. Audio quality will be improved by adding features such as high definition (both high frequency and high resolution sampling) and multichannel (for example, 7.1 surround sound) audio support. 2. Decision & Precedence Information The project is approved as specified in reference [1] - [3], but as modified by the required technical change listed in Appendix A below. The project may be delivered in a minor release of the ON consolidation. The project depends on the following other project and may not be delivered before it. LSARC/2009/074 EOF sdtaudiocontrol 3. Interfaces - 2 - The project exports the following interfaces. ______________________________________________________________________________ | Interfaces Exported | |______________________|_______________________|_____________________________| |Interface | Classification | Comments | |______________________|_______________________|_____________________________| |audio(7I) | Obsolete Committed | We've marked this API as | | | | Obsolete. We've also | | | | changed some semantics in | | | | ways that we believe are | | | | compatible. | | | | See the specification | | | | for more detail. | |mixer(7I) | See comments. | The old Sun mixer(7I) has | | | | been REMOVED. A new OSSv4 | | | | API is provided in its | | | | place with Uncommitted | | | | binding. | | | | See the specification for | | | | more detail. | |OSS API | Uncommitted | External userland API spec.| |/dev/sndstat | Uncommitted | Node for finding OSS dev | | | | nodes. | |/dev/audio | Obsolete Committed | Legacy Sun | |/dev/audioctl | Obsolete Committed | Legacy Sun | |/dev/sound/[0-9]+ | Obsolete Committed | Legacy Sun | |/dev/sound/[0-9]+ctl | Obsolete Committed | Legacy Sun | |/dev/mixer | Uncommitted | Symbolic link to | | | | /dev/sndstat | |/dev/dsp | Uncommitted | File name may change. | |Boomer DDI | Consolidation Private| New device driver API | |ac97 DDI | Consolidation Private| AC'97 support routines. | |SADA DDI | REMOVED | Legacy device driver API | |amsrc2 | REMOVED | | |mixer(7d) | REMOVED | | |audiosup(7d) | REMOVED | | |mixerctl(1) | Uncommitted | New CLI switches, may raise| | | | commitment later. | |audio control names | Uncommitted | ASCIIZ representation for | | | | hardware audio controls. | |audioplay -p & -m | REMOVED | Per TCA | |audiorecord -p & -m | REMOVED | Per TCA | |Client Personality API| Project Private | "audio_client.h" header. | |audiopci | Uncommitted | New audio driver. | |______________________|_______________________|_____________________________| - 3 - The project imports the following interfaces. ______________________________________________________________ | Interfaces Imported | |_________|_____________________|____________________________| |Interface| Classification | Comments | |_________|_____________________|____________________________| |OSS API | Uncommitted | We implement this API, but| | | | it is an external | | | | specification. | |audio(7I)| Obsoleted Committed| We implement these APIs | |_________|_____________________|____________________________| 4. Opinion 4.1. sdtaudiocontrol dependency A member wanted to understand if sdtaudiocontrol should be removed from Nevada before Boomer integration. The project team noted that LSARC/2009/074 EOF sdtaudiocontrol has been filed. In addition, LSARC/2009/074 is noted as a dependency for this case and the project team will file a bug. 4.2. digital telephone interface support A member questioned if Boomer could architecturally support digital telephone interfaces which are inherently 8-bit mu- law PCM (or A-law in Europe). The project team clarified that there is no support currently in Boomer to handle tele- phone inputs, but that Boomer could support these interfaces if there was a need. 4.3. audioplay and audiorecord command line options A member asked if the disabled command line options in audioplay and audiorecord will have an EOF announcement. Other members stated that having the functionality of the command line options available and not work properly was problematic. The project team noted that these command line options were still available due to concern over breaking programs that depend on them. The project team decided that this concern was not a strong enough reason and agreed to a TCR to make the EOF announcement regarding the command line options. Also, the project team agreed to a TCA to remove disabled command line options that handle port selection and master settings such as volume control and monitor gain. 4.4. audigy and SADA DDI Since the audigy driver will not be supported in phase I, a member asked about the support of the public SADA inter- faces. The project team clarified that the SADA interfaces - 4 - are actually consolidation private and not public. 5. Minority Opinion(s) None. 6. Advisory Information None. 7. Appendices 7.1. Appendix A: Technical Changes Required 1. The project team will make an EOF announcement about disabled audioplay and audiorecord command line options. 7.2. Appendix B: Technical Changes Advised 1. The project team will remove disabled command line options that handle port selection and master settings such as volume control and monitor gain. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2008/318. 1. 20 Questions File: inception.materials/boomer.20q 2. Project Specification File: commitment.materials/boomer.pdf 3. Issues and Responses File: issues 4. Man Page for dsp OSS API File: commitment.materials/dsp.7I 5. Man Page for mixer OSS API File: commitment.materials/mixer.7I 6. Community OSS website http://developer.opensound.com/ --Boundary_(ID_zFAAoM67rZp6Pf6zTa3lZg)-- From sac-owner Tue Mar 17 02:34:18 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2H9YIdK017532 for ; Tue, 17 Mar 2009 02:34:18 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2H9YFxk039925 for <@sunmail2sca.sfbay.sun.com:sac-review@sun.com>; Tue, 17 Mar 2009 03:34:17 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KGN00K3R994AI00@nwk-avmta-2.sfbay.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Tue, 17 Mar 2009 02:34:16 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KGN00B0C990SOA0@nwk-avmta-2.sfbay.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Tue, 17 Mar 2009 02:34:13 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2H9YCRf011158 for ; Tue, 17 Mar 2009 09:34:12 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KGN00E008E4MS00@fe-emea-09.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Tue, 17 Mar 2009 09:34:12 +0000 (GMT) Received: from [129.156.173.21] ([unknown] [129.156.173.21]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KGN003PW98JR8D0@fe-emea-09.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Tue, 17 Mar 2009 09:33:56 +0000 (GMT) Date: Tue, 17 Mar 2009 09:33:55 +0000 From: Darren J Moffat Subject: Re: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio In-reply-to: <49BECD71.8020905@Sun.COM> Sender: Darren.Moffat@sun.com To: Phi Tran Cc: sac-review@sun.com Message-id: <49BF6E83.6070200@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49BECD71.8020905@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1430 Sorry I missed commenting on this during the PSARC opinion review period. I followed this case and had comments even though I wasn't part of the committee present on the commitment review day. Given that I'm happy to be listed as a voting member. I'd vote to approve but with one additional piece of advice in the opinion. I strongly believe that the opinion for this case needs to mention the issues with Sun Ray. In particular it needs to point out that this case does not deliver the new functionality for Sun Ray DTUs and that additional work needs to be done. It should in my opinion also point out that the continuance of the Sun Ray architecture reviews not being done in a SAC sanctioned body makes it difficult for the ARC to require that project teams like this actually work with Sun Ray. We need to stop Sun Ray and Solaris/OpenSolaris working on a different schedule. It is vital that Sun Ray be fully functional on OpenSolaris and that it be able to take advantage of cases like this when they initially deliver instead of being a later case consideration. This part of the opinion is directed not at the Solaris PAC but directly at Jeff Jackson and his reports. This case is just one of a number of areas where we have recently seen issues with Sun Ray for a case under review. I'd be happy to provide a version of the above suitable for inclusion in the opinion. -- Darren J Moffat From sac-owner Tue Mar 17 06:18:26 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2HDIP8m015616 for ; Tue, 17 Mar 2009 06:18:25 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2HDIEBN007228; Tue, 17 Mar 2009 13:18:22 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KGN0091BJMILE00@nwk-avmta-2.sfbay.sun.com>; Tue, 17 Mar 2009 06:18:18 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KGN002HAJMHNP90@nwk-avmta-2.sfbay.sun.com>; Tue, 17 Mar 2009 06:18:18 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n2HDIAx3013224; Tue, 17 Mar 2009 09:18:10 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n2HDIARE013221; Tue, 17 Mar 2009 09:18:10 -0400 (EDT) Date: Tue, 17 Mar 2009 09:18:10 -0400 From: James Carlson Subject: Re: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio In-reply-to: <49BF6E83.6070200@Sun.COM> To: Darren J Moffat Cc: Phi Tran , sac-review@sun.com Message-id: <18879.41746.834867.512769@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49BECD71.8020905@Sun.COM> <49BF6E83.6070200@Sun.COM> Status: RO Content-Length: 1368 Darren J Moffat writes: > I'd vote to approve but with one additional piece of advice in the > opinion. I strongly believe that the opinion for this case needs to > mention the issues with Sun Ray. In particular it needs to point out > that this case does not deliver the new functionality for Sun Ray DTUs > and that additional work needs to be done. It should in my opinion also > point out that the continuance of the Sun Ray architecture reviews not > being done in a SAC sanctioned body makes it difficult for the ARC to > require that project teams like this actually work with Sun Ray. We > need to stop Sun Ray and Solaris/OpenSolaris working on a different > schedule. It is vital that Sun Ray be fully functional on OpenSolaris > and that it be able to take advantage of cases like this when they > initially deliver instead of being a later case consideration. This > part of the opinion is directed not at the Solaris PAC but directly at > Jeff Jackson and his reports. This case is just one of a number of > areas where we have recently seen issues with Sun Ray for a case under > review. A big +1 to that. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sac-owner Tue Mar 17 08:25:30 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2HFPTNE011137 for ; Tue, 17 Mar 2009 08:25:30 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n2HFPQvp014167 for <@sunmail2sca.sfbay.sun.com:sac-review@sun.com>; Tue, 17 Mar 2009 23:25:28 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KGN00F01PIFW200@nwk-avmta-2.sfbay.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Tue, 17 Mar 2009 08:25:27 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KGN00DKKPIF9G50@nwk-avmta-2.sfbay.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Tue, 17 Mar 2009 08:25:27 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2HFPQLM061392; Tue, 17 Mar 2009 08:25:26 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id n2HFPwMT009622; Tue, 17 Mar 2009 07:25:58 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id n2HFPwLn009621; Tue, 17 Mar 2009 08:25:58 -0700 (PDT) Date: Tue, 17 Mar 2009 08:25:58 -0700 (PDT) From: Gary Winiger Subject: Re: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio To: Phi.Tran@sun.com, Darren.Moffat@sun.com Cc: sac-review@sun.com Message-id: <200903171525.n2HFPwLn009621@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1951 > Sorry I missed commenting on this during the PSARC opinion review period. > > I followed this case and had comments even though I wasn't part of the > committee present on the commitment review day. Given that I'm happy to > be listed as a voting member. I didn't follow up for the commitment review and will remain NP. And I completely agree with Dareen re: SunRay's continued insistance to "work around Solaris" rather than "work within Solaris." It comes up again and again. Viz the recent Xnewt. On the current delivery of OSol, SRSS and TX are no longer compatible. Other examples exist. I realize that there are business decisions. Architecturally this has been going on since 1999/219-223. Gary.. > I'd vote to approve but with one additional piece of advice in the > opinion. I strongly believe that the opinion for this case needs to > mention the issues with Sun Ray. In particular it needs to point out > that this case does not deliver the new functionality for Sun Ray DTUs > and that additional work needs to be done. It should in my opinion also > point out that the continuance of the Sun Ray architecture reviews not > being done in a SAC sanctioned body makes it difficult for the ARC to > require that project teams like this actually work with Sun Ray. We > need to stop Sun Ray and Solaris/OpenSolaris working on a different > schedule. It is vital that Sun Ray be fully functional on OpenSolaris > and that it be able to take advantage of cases like this when they > initially deliver instead of being a later case consideration. This > part of the opinion is directed not at the Solaris PAC but directly at > Jeff Jackson and his reports. This case is just one of a number of > areas where we have recently seen issues with Sun Ray for a case under > review. > > I'd be happy to provide a version of the above suitable for inclusion in > the opinion. > > -- > Darren J Moffat > From sac-owner Tue Mar 17 09:10:13 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2HGADZd012735 for ; Tue, 17 Mar 2009 09:10:13 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2HGA8BF005091 for <@sunmail2sca.sfbay.sun.com:sac-review@sun.com>; Tue, 17 Mar 2009 10:10:13 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KGN00D15RL0N300@nwk-avmta-1.sfbay.Sun.COM> for sac-review@sun.com (ORCPT sac-review@sun.com); Tue, 17 Mar 2009 09:10:12 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KGN00LJPRKZV1D0@nwk-avmta-1.sfbay.Sun.COM> for sac-review@sun.com (ORCPT sac-review@sun.com); Tue, 17 Mar 2009 09:10:11 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2HGABR6028524 for ; Tue, 17 Mar 2009 09:10:11 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KGN00700QTMEB00@fe-sfbay-10.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Tue, 17 Mar 2009 09:10:11 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KGN00774RKWQ720@fe-sfbay-10.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Tue, 17 Mar 2009 09:10:10 -0700 (PDT) Date: Tue, 17 Mar 2009 09:10:08 -0700 From: "Garrett D'Amore" Subject: Re: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio In-reply-to: <18879.41746.834867.512769@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: James Carlson Cc: Darren J Moffat , Phi Tran , sac-review@sun.com Message-id: <49BFCB60.8030909@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49BECD71.8020905@Sun.COM> <49BF6E83.6070200@Sun.COM> <18879.41746.834867.512769@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1363 James Carlson wrote: > Darren J Moffat writes: > >> I'd vote to approve but with one additional piece of advice in the >> opinion. I strongly believe that the opinion for this case needs to >> mention the issues with Sun Ray. In particular it needs to point out >> that this case does not deliver the new functionality for Sun Ray DTUs >> and that additional work needs to be done. It should in my opinion also >> point out that the continuance of the Sun Ray architecture reviews not >> being done in a SAC sanctioned body makes it difficult for the ARC to >> require that project teams like this actually work with Sun Ray. We >> need to stop Sun Ray and Solaris/OpenSolaris working on a different >> schedule. It is vital that Sun Ray be fully functional on OpenSolaris >> and that it be able to take advantage of cases like this when they >> initially deliver instead of being a later case consideration. This >> part of the opinion is directed not at the Solaris PAC but directly at >> Jeff Jackson and his reports. This case is just one of a number of >> areas where we have recently seen issues with Sun Ray for a case under >> review. >> > > A big +1 to that. > > I agree with this as well. Darren, can you write the exact text that you think should be included, and send it to Phi and myself? Thanks. -- Garrett From sac-owner Tue Mar 17 10:08:36 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2HH8abv014587 for ; Tue, 17 Mar 2009 10:08:36 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2HH8Vku057342; Tue, 17 Mar 2009 11:08:34 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KGN00L3TUAAB600@nwk-avmta-2.sfbay.sun.com>; Tue, 17 Mar 2009 10:08:34 -0700 (PDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KGN00DI9UA99OE0@nwk-avmta-2.sfbay.sun.com>; Tue, 17 Mar 2009 10:08:33 -0700 (PDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id n2HH8XHH016249; Tue, 17 Mar 2009 17:08:33 +0000 (GMT) Date: Tue, 17 Mar 2009 10:08:31 -0700 From: Bart Smaalders Subject: Re: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio In-reply-to: <49BF6E83.6070200@Sun.COM> To: Darren J Moffat Cc: Phi Tran , sac-review@sun.com Message-id: <49BFD90F.7040104@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49BECD71.8020905@Sun.COM> <49BF6E83.6070200@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20090211) Status: RO Content-Length: 721 Darren J Moffat wrote: > This case is just one of a number of > areas where we have recently seen issues with Sun Ray for a case under > review. My discussions w/ Jerry Wall of the SunRay team last year regarding audio virtualization on Solaris were completely fruitless ; the team is apparently uninterested working together with the Solaris organization and Jerry managed to convey this very clearly. Unless our shared management chain applies significant coercion, I do not expect them to take Solaris, OpenSolaris or PSARC into account. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From sac-owner Tue Mar 17 10:21:49 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2HHLn33014833 for ; Tue, 17 Mar 2009 10:21:49 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2HHLhUp020452; Tue, 17 Mar 2009 10:21:47 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KGN00L4ZUWBO600@nwk-avmta-1.sfbay.Sun.COM>; Tue, 17 Mar 2009 10:21:47 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KGN00HA0UWAOP40@nwk-avmta-1.sfbay.Sun.COM>; Tue, 17 Mar 2009 10:21:46 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n2HHLdJE029174; Tue, 17 Mar 2009 13:21:39 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n2HHLdt9029171; Tue, 17 Mar 2009 13:21:39 -0400 (EDT) Date: Tue, 17 Mar 2009 13:21:39 -0400 From: James Carlson Subject: Re: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio In-reply-to: <49BFD90F.7040104@Sun.COM> To: Bart Smaalders Cc: Darren J Moffat , Phi Tran , sac-review@sun.com Message-id: <18879.56355.727111.331214@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49BECD71.8020905@Sun.COM> <49BF6E83.6070200@Sun.COM> <49BFD90F.7040104@Sun.COM> Status: RO Content-Length: 1156 Bart Smaalders writes: > Darren J Moffat wrote: > > This case is just one of a number of > > areas where we have recently seen issues with Sun Ray for a case under > > review. > > My discussions w/ Jerry Wall of the SunRay team last year regarding > audio virtualization on Solaris were completely fruitless ; the team is > apparently uninterested working together with the Solaris organization > and Jerry managed to convey this very clearly. > > Unless our shared management chain applies significant coercion, I do > not expect them to take Solaris, OpenSolaris or PSARC into account. I can believe that's true, but I still think that the ARC has a responsibility to note the problems when they're seen, as is true in this case. If we don't do at least that -- if we just keep quiet because we think either nobody's listening or that those listening are unable or unwilling to do anything -- then we're part of the problem. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sac-owner Tue Mar 17 10:28:30 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2HHSTNN015017 for ; Tue, 17 Mar 2009 10:28:29 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2HHSPCD007515; Tue, 17 Mar 2009 11:28:27 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KGN00M1XV7FBN00@nwk-avmta-2.sfbay.sun.com>; Tue, 17 Mar 2009 10:28:27 -0700 (PDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KGN00LX3V7EKP10@nwk-avmta-2.sfbay.sun.com>; Tue, 17 Mar 2009 10:28:26 -0700 (PDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id n2HHSQoF016809; Tue, 17 Mar 2009 17:28:26 +0000 (GMT) Date: Tue, 17 Mar 2009 10:28:24 -0700 From: Bart Smaalders Subject: Re: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio In-reply-to: <18879.56355.727111.331214@gargle.gargle.HOWL> To: James Carlson Cc: Darren J Moffat , Phi Tran , sac-review@sun.com Message-id: <49BFDDB8.7070803@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49BECD71.8020905@Sun.COM> <49BF6E83.6070200@Sun.COM> <49BFD90F.7040104@Sun.COM> <18879.56355.727111.331214@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.18 (X11/20090211) Status: RO Content-Length: 1301 James Carlson wrote: > Bart Smaalders writes: >> Darren J Moffat wrote: >>> This case is just one of a number of >>> areas where we have recently seen issues with Sun Ray for a case under >>> review. >> My discussions w/ Jerry Wall of the SunRay team last year regarding >> audio virtualization on Solaris were completely fruitless ; the team is >> apparently uninterested working together with the Solaris organization >> and Jerry managed to convey this very clearly. >> >> Unless our shared management chain applies significant coercion, I do >> not expect them to take Solaris, OpenSolaris or PSARC into account. > > I can believe that's true, but I still think that the ARC has a > responsibility to note the problems when they're seen, as is true in > this case. If we don't do at least that -- if we just keep quiet > because we think either nobody's listening or that those listening are > unable or unwilling to do anything -- then we're part of the problem. > I completely agree... but don't expect anything to change; their organization apparently has very different goals compared to the rest of software.... - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From sac-owner Tue Mar 17 10:36:43 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2HHahmH015076 for ; Tue, 17 Mar 2009 10:36:43 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2HHadHo018367 for <@sunmail2sca.sfbay.sun.com:sac-review@sun.com>; Tue, 17 Mar 2009 10:36:43 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KGN0090JVL67X00@brm-avmta-1.central.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Tue, 17 Mar 2009 11:36:42 -0600 (MDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KGN00279VL58290@brm-avmta-1.central.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Tue, 17 Mar 2009 11:36:41 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2HHadSe052432; Tue, 17 Mar 2009 10:36:39 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id n2HHbCIt009797; Tue, 17 Mar 2009 09:37:12 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id n2HHbBwY009796; Tue, 17 Mar 2009 10:37:11 -0700 (PDT) Date: Tue, 17 Mar 2009 10:37:11 -0700 (PDT) From: Gary Winiger Subject: Re: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio To: james.d.carlson@sun.com, bart.smaalders@sun.com Cc: Darren.Moffat@sun.com, Phi.Tran@sun.com, sac-review@sun.com Message-id: <200903171737.n2HHbBwY009796@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1199 Bart writes: > James Carlson wrote: > > Bart Smaalders writes: > >> Darren J Moffat wrote: > >>> This case is just one of a number of > >>> areas where we have recently seen issues with Sun Ray for a case under > >>> review. > >> My discussions w/ Jerry Wall of the SunRay team last year regarding > >> audio virtualization on Solaris were completely fruitless ; the team is > >> apparently uninterested working together with the Solaris organization > >> and Jerry managed to convey this very clearly. > >> > >> Unless our shared management chain applies significant coercion, I do > >> not expect them to take Solaris, OpenSolaris or PSARC into account. > > > > I can believe that's true, but I still think that the ARC has a > > responsibility to note the problems when they're seen, as is true in > > this case. If we don't do at least that -- if we just keep quiet > > because we think either nobody's listening or that those listening are > > unable or unwilling to do anything -- then we're part of the problem. > > > > I completely agree... but don't expect anything to change; their > organization apparently has very different goals compared to the > rest of software.... +1 Gary.. From sac-owner Tue Mar 24 10:28:32 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2OHSWC7015019 for ; Tue, 24 Mar 2009 10:28:32 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2OHST0Y012993 for <@sunmail2sca.sfbay.sun.com:sac-review@sun.com>; Tue, 24 Mar 2009 10:28:32 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KH000C2FTVJ5S00@brm-avmta-1.central.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Tue, 24 Mar 2009 11:28:31 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KH0009DZTVJI830@brm-avmta-1.central.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Tue, 24 Mar 2009 11:28:31 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2OHSVDZ021426 for ; Tue, 24 Mar 2009 10:28:31 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KH000100TRFJK00@fe-sfbay-10.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Tue, 24 Mar 2009 10:28:30 -0700 (PDT) Received: from [10.1.48.53] ([unknown] [10.1.48.53]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KH0009FETV8ZJI0@fe-sfbay-10.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Tue, 24 Mar 2009 10:28:20 -0700 (PDT) Date: Tue, 24 Mar 2009 10:28:23 -0700 From: Phi Tran Subject: Re: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio In-reply-to: <49BECD71.8020905@Sun.COM> Sender: Phi.Tran@sun.com To: sac-review@sun.com Message-id: <49C91837.2040200@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49BECD71.8020905@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 675 It was discussed that Sun Ray issues should be added to the opinion. Thus, the following will be added to the opinion in section 6. Advisory Information. Please send any comments by Friday. Thanks. "Several members expressed disappointment that the Sun Ray support is not included as part of this project's deliverables. Disappointment was also expressed with the fact that Sun Ray development often appears disconnected with the rest of the development of Solaris. Going forward, these members would like to see closer cooperation between the Sun Ray project and the Solaris project, including having the appropriate Sun Ray components reviewed by PSARC." Phi From sac-owner Wed Mar 25 10:45:43 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2PHjhcr020587 for ; Wed, 25 Mar 2009 10:45:43 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2PHjNi9024270 for <@sunmail2sca.sfbay.sun.com:sac-review@sun.com>; Wed, 25 Mar 2009 10:45:43 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KH200A01PC6CQ00@brm-avmta-1.central.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 11:45:42 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KH2001SCPC56I60@brm-avmta-1.central.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 11:45:41 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2PHjfHv022534 for ; Wed, 25 Mar 2009 17:45:41 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KH200B00NF6D300@mail-amer.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 11:45:41 -0600 (MDT) Received: from [192.168.10.7] ([unknown] [76.20.56.47]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KH20097QPBL54D0@mail-amer.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 11:45:22 -0600 (MDT) Date: Wed, 25 Mar 2009 10:44:27 -0700 From: John Fischer Subject: Re: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio In-reply-to: <49C91837.2040200@Sun.COM> Sender: John.Fischer@sun.com To: Phi Tran Cc: sac-review@sun.com Reply-to: John.Fischer@sun.com Message-id: <49CA6D7B.9060607@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49BECD71.8020905@Sun.COM> <49C91837.2040200@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20090211) Status: RO Content-Length: 1076 Phi, The last word needs to be changed. I can see some components reviewed by PSARC while others reviewed by LSARC. Thus it should read something like: .... including having the appropriate Sun Ray components reviewed by the appropriate architectural committee and made visible to the rest of the Sun engineering community. Thanks, John Phi Tran wrote: > It was discussed that Sun Ray issues should be added to the opinion. > Thus, the following will be added to the opinion in section 6. Advisory > Information. Please send any comments by Friday. Thanks. > > "Several members expressed disappointment that the Sun Ray support is > not included as part of this project's deliverables. Disappointment was > also expressed with the fact that Sun Ray development often appears > disconnected with the rest of the development of Solaris. Going > forward, these members would like to see closer cooperation between the > Sun Ray project and the Solaris project, including having the > appropriate Sun Ray components reviewed by PSARC." > > Phi From sac-owner Wed Mar 25 11:13:54 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2PIDsYp023923 for ; Wed, 25 Mar 2009 11:13:54 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2PIDiU3025596 for <@sunmail2sca.sfbay.sun.com:sac-review@sun.com>; Wed, 25 Mar 2009 11:13:54 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KH200C01QN5WV00@brm-avmta-1.central.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 12:13:53 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KH2001BRQN56M90@brm-avmta-1.central.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 12:13:53 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2PIDqgP013410 for ; Wed, 25 Mar 2009 11:13:52 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KH200M00Q0QV700@fe-sfbay-10.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 11:13:52 -0700 (PDT) Received: from [10.1.48.53] ([unknown] [10.1.48.53]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KH2004ZLQN0VQB0@fe-sfbay-10.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 11:13:48 -0700 (PDT) Date: Wed, 25 Mar 2009 11:13:51 -0700 From: Phi Tran Subject: Re: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio In-reply-to: <49CA6D7B.9060607@sun.com> Sender: Phi.Tran@sun.com To: John.Fischer@sun.com Cc: sac-review@sun.com Message-id: <49CA745F.6070105@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49BECD71.8020905@Sun.COM> <49C91837.2040200@Sun.COM> <49CA6D7B.9060607@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 1617 John Fischer wrote: > Phi, > > The last word needs to be changed. I can see some components reviewed > by PSARC while others reviewed by LSARC. Thus it should read something > like: > > .... including having the appropriate Sun Ray components reviewed by > the appropriate architectural committee and made visible to the rest > of the Sun engineering community. I agree that the statement should not be specific to PSARC, but I don't think the part about being visible to the Sun engineering community is needed since it is implied and to be specific, it will sometimes be visible to the opensolaris community for open cases, not just the Sun engineering community. How about just change the ending to: .... including having the appropriate Sun Ray components reviewed by the appropriate architectural committee. Thanks, Phi > > Thanks, > > John > > Phi Tran wrote: >> It was discussed that Sun Ray issues should be added to the opinion. >> Thus, the following will be added to the opinion in section 6. >> Advisory Information. Please send any comments by Friday. Thanks. >> >> "Several members expressed disappointment that the Sun Ray support is >> not included as part of this project's deliverables. Disappointment >> was also expressed with the fact that Sun Ray development often >> appears disconnected with the rest of the development of Solaris. >> Going forward, these members would like to see closer cooperation >> between the Sun Ray project and the Solaris project, including having >> the appropriate Sun Ray components reviewed by PSARC." >> >> Phi From sac-owner Wed Mar 25 11:17:00 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2PIH0vt024292 for ; Wed, 25 Mar 2009 11:17:00 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2PIGufK046253 for <@sunmail2sca.sfbay.sun.com:sac-review@sun.com>; Wed, 25 Mar 2009 12:17:00 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KH20084CQS9HR00@nwk-avmta-1.sfbay.Sun.COM> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 11:16:57 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KH2001XNQS9TL50@nwk-avmta-1.sfbay.Sun.COM> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 11:16:57 -0700 (PDT) Received: from [10.6.102.118] (sunray-sxde.SFBay.Sun.COM [10.6.102.118]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id n2PIGu8Q024056; Wed, 25 Mar 2009 11:16:56 -0700 (PDT) Date: Wed, 25 Mar 2009 11:16:56 -0700 From: Alan Coopersmith Subject: Re: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio In-reply-to: <49CA745F.6070105@Sun.COM> To: Phi Tran Cc: John.Fischer@sun.com, sac-review@sun.com Message-id: <49CA7518.4020509@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <49BECD71.8020905@Sun.COM> <49C91837.2040200@Sun.COM> <49CA6D7B.9060607@sun.com> <49CA745F.6070105@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 497 Phi Tran wrote: > How about just change the ending to: > > .... including having the appropriate Sun Ray components reviewed by > the appropriate architectural committee. Does that imply that Sun Ray's "IA-SWARC" is not "the appropriate architectural committee"? If that's what you mean, you should say so, since otherwise management is likely to assume it already is. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sac-owner Wed Mar 25 11:24:24 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2PIONGO024896 for ; Wed, 25 Mar 2009 11:24:24 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n2PIOJ7F003267 for <@sunmail2sca.sfbay.sun.com:sac-review@sun.com>; Thu, 26 Mar 2009 02:24:22 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KH200D05R4L9I00@nwk-avmta-2.sfbay.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 11:24:21 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KH200B39R4KO920@nwk-avmta-2.sfbay.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 11:24:20 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2PIOKR6013298 for ; Wed, 25 Mar 2009 18:24:20 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KH200F00QLYC500@mail-amer.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 12:24:20 -0600 (MDT) Received: from [192.168.10.7] ([unknown] [76.20.56.47]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KH200HAWR45ZZC0@mail-amer.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 12:24:06 -0600 (MDT) Date: Wed, 25 Mar 2009 11:23:11 -0700 From: John Fischer Subject: Re: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio In-reply-to: <49CA7518.4020509@sun.com> Sender: John.Fischer@sun.com To: Alan Coopersmith Cc: Phi Tran , sac-review@sun.com Reply-to: John.Fischer@sun.com Message-id: <49CA768F.2080401@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49BECD71.8020905@Sun.COM> <49C91837.2040200@Sun.COM> <49CA6D7B.9060607@sun.com> <49CA745F.6070105@Sun.COM> <49CA7518.4020509@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090211) Status: RO Content-Length: 578 Phi, Alan points out what I was trying to avoid. Perhaps the advice really is that the IA_SWARC needs to be brought under the SAC umbrella. Thanks, John Alan Coopersmith wrote: > Phi Tran wrote: >> How about just change the ending to: >> >> .... including having the appropriate Sun Ray components reviewed by >> the appropriate architectural committee. > > Does that imply that Sun Ray's "IA-SWARC" is not "the appropriate architectural > committee"? If that's what you mean, you should say so, since otherwise > management is likely to assume it already is. > From sac-owner Wed Mar 25 11:32:00 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2PIVxtS025282 for ; Wed, 25 Mar 2009 11:32:00 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2PIVvAY058157; Wed, 25 Mar 2009 12:31:59 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KH200A0RRH98X00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Mar 2009 11:31:57 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KH2001V2RH9TS70@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Mar 2009 11:31:57 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n2PIVgpS006613; Wed, 25 Mar 2009 14:31:42 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n2PIVgTT006610; Wed, 25 Mar 2009 14:31:42 -0400 (EDT) Date: Wed, 25 Mar 2009 14:31:42 -0400 From: James Carlson Subject: Re: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio In-reply-to: <49CA768F.2080401@sun.com> To: John.Fischer@sun.com Cc: Alan Coopersmith , Phi Tran , sac-review@sun.com Message-id: <18890.30862.905181.506634@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49BECD71.8020905@Sun.COM> <49C91837.2040200@Sun.COM> <49CA6D7B.9060607@sun.com> <49CA745F.6070105@Sun.COM> <49CA7518.4020509@sun.com> <49CA768F.2080401@sun.com> Status: RO Content-Length: 401 John Fischer writes: > Alan points out what I was trying to avoid. > Perhaps the advice really is that the IA_SWARC > needs to be brought under the SAC umbrella. Yes; exactly. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sac-owner Wed Mar 25 11:36:44 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2PIahJQ025724 for ; Wed, 25 Mar 2009 11:36:43 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2PIaer1019477 for <@sunmail2sca.sfbay.sun.com:sac-review@sun.com>; Wed, 25 Mar 2009 18:36:42 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KH200A0XRP3ST00@nwk-avmta-1.sfbay.Sun.COM> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 11:36:39 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KH20011LRP2TS80@nwk-avmta-1.sfbay.Sun.COM> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 11:36:38 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2PIacuG016925 for ; Wed, 25 Mar 2009 11:36:38 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KH200M00Q0QV700@fe-sfbay-10.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 11:36:38 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KH20044VROU4D40@fe-sfbay-10.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 11:36:30 -0700 (PDT) Date: Wed, 25 Mar 2009 11:36:29 -0700 From: "Garrett D'Amore" Subject: Re: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio In-reply-to: <49CA768F.2080401@sun.com> Sender: Garrett.Damore@sun.com To: John.Fischer@sun.com Cc: Alan Coopersmith , Phi Tran , sac-review@sun.com Message-id: <49CA79AD.5080109@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49BECD71.8020905@Sun.COM> <49C91837.2040200@Sun.COM> <49CA6D7B.9060607@sun.com> <49CA745F.6070105@Sun.COM> <49CA7518.4020509@sun.com> <49CA768F.2080401@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 844 John Fischer wrote: > Phi, > > Alan points out what I was trying to avoid. > Perhaps the advice really is that the IA_SWARC > needs to be brought under the SAC umbrella. All that said, this advice is actually getting pretty far from the core issues that concern Boomer. I want to make some statement here, but I don't want to take too long to craft it. -- Garrett > > Thanks, > > John > > Alan Coopersmith wrote: >> Phi Tran wrote: >>> How about just change the ending to: >>> >>> .... including having the appropriate Sun Ray components >>> reviewed by >>> the appropriate architectural committee. >> >> Does that imply that Sun Ray's "IA-SWARC" is not "the appropriate >> architectural >> committee"? If that's what you mean, you should say so, since >> otherwise >> management is likely to assume it already is. >> > From sac-owner Wed Mar 25 11:53:11 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2PIrA18026361 for ; Wed, 25 Mar 2009 11:53:11 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2PIr2wi029244 for <@sunmail2sca.sfbay.sun.com:sac-review@sun.com>; Wed, 25 Mar 2009 18:53:10 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KH200C0HSGLO500@nwk-avmta-1.sfbay.Sun.COM> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 11:53:09 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KH2001FESGKTMB0@nwk-avmta-1.sfbay.Sun.COM> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 11:53:09 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2PIr8f1005523 for ; Wed, 25 Mar 2009 18:53:08 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KH200J00RIVQ400@mail-amer.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 12:53:08 -0600 (MDT) Received: from [192.168.10.7] ([unknown] [76.20.56.47]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KH200470SGK8770@mail-amer.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 12:53:08 -0600 (MDT) Date: Wed, 25 Mar 2009 11:52:13 -0700 From: John Fischer Subject: Re: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio In-reply-to: <49CA79AD.5080109@sun.com> Sender: John.Fischer@sun.com To: "Garrett D'Amore" Cc: Alan Coopersmith , Phi Tran , sac-review@sun.com Reply-to: John.Fischer@sun.com Message-id: <49CA7D5D.2070200@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49BECD71.8020905@Sun.COM> <49C91837.2040200@Sun.COM> <49CA6D7B.9060607@sun.com> <49CA745F.6070105@Sun.COM> <49CA7518.4020509@sun.com> <49CA768F.2080401@sun.com> <49CA79AD.5080109@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090211) Status: RO Content-Length: 1070 Garrett, Alternatively, you could remove Sun from my suggestion as this could then include Sun engineering and the Open community at large. Thanks, John Garrett D'Amore wrote: > John Fischer wrote: >> Phi, >> >> Alan points out what I was trying to avoid. >> Perhaps the advice really is that the IA_SWARC >> needs to be brought under the SAC umbrella. > > All that said, this advice is actually getting pretty far from the core > issues that concern Boomer. > > I want to make some statement here, but I don't want to take too long to > craft it. > > -- Garrett > >> >> Thanks, >> >> John >> >> Alan Coopersmith wrote: >>> Phi Tran wrote: >>>> How about just change the ending to: >>>> >>>> .... including having the appropriate Sun Ray components >>>> reviewed by >>>> the appropriate architectural committee. >>> >>> Does that imply that Sun Ray's "IA-SWARC" is not "the appropriate >>> architectural >>> committee"? If that's what you mean, you should say so, since >>> otherwise >>> management is likely to assume it already is. >>> >> > From sac-owner Wed Mar 25 11:59:53 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2PIxqdx026934 for ; Wed, 25 Mar 2009 11:59:53 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2PIxpmJ003224 for <@sunmail2sca.sfbay.sun.com:sac-review@sun.com>; Wed, 25 Mar 2009 18:59:52 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KH200F0BSRR1J00@nwk-avmta-2.sfbay.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 11:59:51 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KH200BVOSRROO40@nwk-avmta-2.sfbay.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 11:59:51 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2PIxpiD002205 for ; Wed, 25 Mar 2009 11:59:51 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KH200600PLDJ900@fe-sfbay-10.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 11:59:51 -0700 (PDT) Received: from [10.1.48.53] ([unknown] [10.1.48.53]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KH2004EMSRE4DE0@fe-sfbay-10.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 11:59:38 -0700 (PDT) Date: Wed, 25 Mar 2009 11:59:41 -0700 From: Phi Tran Subject: Re: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio In-reply-to: <49CA768F.2080401@sun.com> Sender: Phi.Tran@Sun.COM To: John.Fischer@Sun.COM Cc: Alan Coopersmith , sac-review@Sun.COM Message-id: <49CA7F1D.3030001@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49BECD71.8020905@Sun.COM> <49C91837.2040200@Sun.COM> <49CA6D7B.9060607@sun.com> <49CA745F.6070105@Sun.COM> <49CA7518.4020509@sun.com> <49CA768F.2080401@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 844 John Fischer wrote: > Phi, > > Alan points out what I was trying to avoid. > Perhaps the advice really is that the IA_SWARC > needs to be brought under the SAC umbrella. I see. How about this: .... including having the appropriate Sun Ray components reviewed by the appropriate architectural committee and having IA-SWARC brought under the SAC umbrella. Phi > > Thanks, > > John > > Alan Coopersmith wrote: >> Phi Tran wrote: >>> How about just change the ending to: >>> >>> .... including having the appropriate Sun Ray components reviewed by >>> the appropriate architectural committee. >> >> Does that imply that Sun Ray's "IA-SWARC" is not "the appropriate >> architectural >> committee"? If that's what you mean, you should say so, since otherwise >> management is likely to assume it already is. >> > From sac-owner Wed Mar 25 12:06:30 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2PJ6TEu021460 for ; Wed, 25 Mar 2009 12:06:30 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2PJ66o7008634; Wed, 25 Mar 2009 19:06:27 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KH200H05T2OBD00@brm-avmta-1.central.sun.com>; Wed, 25 Mar 2009 13:06:24 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KH2001JOT2K6HC0@brm-avmta-1.central.sun.com>; Wed, 25 Mar 2009 13:06:20 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n2PJ66hg009696; Wed, 25 Mar 2009 15:06:06 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n2PJ66Jr009693; Wed, 25 Mar 2009 15:06:06 -0400 (EDT) Date: Wed, 25 Mar 2009 15:06:06 -0400 From: James Carlson Subject: Re: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio In-reply-to: <49CA7F1D.3030001@Sun.COM> To: Phi Tran Cc: John.Fischer@sun.com, Alan Coopersmith , sac-review@sun.com Message-id: <18890.32926.14810.25552@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49BECD71.8020905@Sun.COM> <49C91837.2040200@Sun.COM> <49CA6D7B.9060607@sun.com> <49CA745F.6070105@Sun.COM> <49CA7518.4020509@sun.com> <49CA768F.2080401@sun.com> <49CA7F1D.3030001@Sun.COM> Status: RO Content-Length: 1035 Phi Tran writes: > John Fischer wrote: > > Phi, > > > > Alan points out what I was trying to avoid. > > Perhaps the advice really is that the IA_SWARC > > needs to be brought under the SAC umbrella. > > I see. How about this: > > .... including having the appropriate Sun Ray components reviewed by > the appropriate architectural committee and having IA-SWARC brought > under the SAC umbrella. better as: ... reviewed by the appropriate architectural committee under SAC or, alternatively, by bringing IA-SWARC under the SAC umbrella. I don't think anyone cares if they feel the need to run their own ARC-like review process. No problem with that; perhaps more should do likewise. The problem is when that ARC-like review is used in place of SAC-sponsored open architectural review. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sac-owner Wed Mar 25 12:17:34 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2PJHYMG021892 for ; Wed, 25 Mar 2009 12:17:34 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2PJHSXB016372 for <@sunmail2sca.sfbay.sun.com:sac-review@sun.com>; Wed, 25 Mar 2009 19:17:33 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KH200I29TL79J00@brm-avmta-1.central.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 13:17:32 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KH2001RATL76MD0@brm-avmta-1.central.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 13:17:31 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2PJHVR1011290 for ; Wed, 25 Mar 2009 19:17:31 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KH200500T6OH600@mail-amer.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 13:17:31 -0600 (MDT) Received: from [192.168.10.7] ([unknown] [76.20.56.47]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KH20049ITKR87D0@mail-amer.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 13:17:15 -0600 (MDT) Date: Wed, 25 Mar 2009 12:16:20 -0700 From: John Fischer Subject: Re: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio In-reply-to: <18890.32926.14810.25552@gargle.gargle.HOWL> Sender: John.Fischer@sun.com To: James Carlson Cc: Phi Tran , Alan Coopersmith , sac-review@sun.com Reply-to: John.Fischer@sun.com Message-id: <49CA8304.1020100@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <49BECD71.8020905@Sun.COM> <49C91837.2040200@Sun.COM> <49CA6D7B.9060607@sun.com> <49CA745F.6070105@Sun.COM> <49CA7518.4020509@sun.com> <49CA768F.2080401@sun.com> <49CA7F1D.3030001@Sun.COM> <18890.32926.14810.25552@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.18 (X11/20090211) Status: RO Content-Length: 1472 Phi, There still seems to be something missing. Again this is an education issue with the reset of the engineering community with respect to the Sun Ray DTU. By issuing the advice we insure that the decisions made about the Sun Ray DTU are seen by the rest of the engineering community. However, we state nothing about the Sun Ray DTU being a requirement for all projects. Perhaps adding to the advice that once IA-SWARC is part of the SAC umbrella we, SAC, can then more easily hold projects to meeting the DTU's requirements. This is the carrot that makes the move to SAC more palatable. Thanks, John James Carlson wrote: > Phi Tran writes: >> John Fischer wrote: >>> Phi, >>> >>> Alan points out what I was trying to avoid. >>> Perhaps the advice really is that the IA_SWARC >>> needs to be brought under the SAC umbrella. >> I see. How about this: >> >> .... including having the appropriate Sun Ray components reviewed by >> the appropriate architectural committee and having IA-SWARC brought >> under the SAC umbrella. > > better as: > > ... reviewed by the appropriate architectural committee under > SAC or, alternatively, by bringing IA-SWARC under the SAC > umbrella. > > I don't think anyone cares if they feel the need to run their own > ARC-like review process. No problem with that; perhaps more should do > likewise. The problem is when that ARC-like review is used in place > of SAC-sponsored open architectural review. > From sac-owner Wed Mar 25 12:31:07 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2PJV6h5022499 for ; Wed, 25 Mar 2009 12:31:06 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n2PJV2St010036 for <@sunmail2sca.sfbay.sun.com:sac-review@sun.com>; Thu, 26 Mar 2009 03:31:05 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KH200G05U7RKS00@nwk-avmta-2.sfbay.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 12:31:04 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KH200BRRU7POB70@nwk-avmta-2.sfbay.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 12:31:01 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2PJV0ZH012376; Wed, 25 Mar 2009 12:31:00 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id n2PJVjUU020575; Wed, 25 Mar 2009 11:31:45 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id n2PJVjJP020574; Wed, 25 Mar 2009 12:31:45 -0700 (PDT) Date: Wed, 25 Mar 2009 12:31:45 -0700 (PDT) From: Gary Winiger Subject: Re: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio To: Phi.Tran@sun.com, james.d.carlson@sun.com Cc: John.Fischer@sun.com, alan.coopersmith@sun.com, sac-review@sun.com Message-id: <200903251931.n2PJVjJP020574@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1255 > > .... including having the appropriate Sun Ray components reviewed by > > the appropriate architectural committee and having IA-SWARC brought > > under the SAC umbrella. > > better as: > > ... reviewed by the appropriate architectural committee under > SAC or, alternatively, by bringing IA-SWARC under the SAC > umbrella. > > I don't think anyone cares if they feel the need to run their own > ARC-like review process. No problem with that; perhaps more should do > likewise. The problem is when that ARC-like review is used in place > of SAC-sponsored open architectural review. SunRay have long felt exempt from the SAC process. Their design review is pretty formal -- and they call it IA-SWARC. I don't believe they need to be told yet again that IA-SWARC is not covered in the SAC process. I believe a more positive thrust, whether or not it's accepted, is what's being desired here. Maybe something more along the lines: "During the review, concerns were expressed over the lack of project alignment between SunRay and OpenSolaris. The committee believes that this lack of alignment could, at least partially, be mitigated by SunRay components being reviewed within the OpenSolaris ARC process." Gary.. From sac-owner Wed Mar 25 12:39:51 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2PJdpt6022832 for ; Wed, 25 Mar 2009 12:39:51 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2PJdoWQ029097 for <@sunmail2sca.sfbay.sun.com:sac-review@sun.com>; Wed, 25 Mar 2009 19:39:50 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KH200K21UMB1900@brm-avmta-1.central.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 13:39:47 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KH2001ODUM86HE0@brm-avmta-1.central.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 13:39:44 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2PJdiW8029280 for ; Wed, 25 Mar 2009 19:39:44 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KH200500T6OH600@mail-amer.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 13:39:44 -0600 (MDT) Received: from [192.168.10.7] ([unknown] [76.20.56.47]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KH200J53ULZZA80@mail-amer.sun.com>; Wed, 25 Mar 2009 13:39:35 -0600 (MDT) Date: Wed, 25 Mar 2009 12:38:40 -0700 From: John Fischer Subject: Re: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio In-reply-to: <200903251931.n2PJVjJP020574@marduk.eng.sun.com> Sender: John.Fischer@sun.com To: Gary Winiger Cc: Phi.Tran@sun.com, James.D.Carlson@sun.com, alan.coopersmith@sun.com, sac-review@sun.com Reply-to: John.Fischer@sun.com Message-id: <49CA8840.4030204@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903251931.n2PJVjJP020574@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090211) Status: RO Content-Length: 1469 Gary, That works for me. Again, this is about getting more of the engineering community to have visibility into the Sun Ray architecture. Thanks, John Gary Winiger wrote: >>> .... including having the appropriate Sun Ray components reviewed by >>> the appropriate architectural committee and having IA-SWARC brought >>> under the SAC umbrella. >> better as: >> >> ... reviewed by the appropriate architectural committee under >> SAC or, alternatively, by bringing IA-SWARC under the SAC >> umbrella. >> >> I don't think anyone cares if they feel the need to run their own >> ARC-like review process. No problem with that; perhaps more should do >> likewise. The problem is when that ARC-like review is used in place >> of SAC-sponsored open architectural review. > > SunRay have long felt exempt from the SAC process. Their design > review is pretty formal -- and they call it IA-SWARC. > I don't believe they need to be told yet again that IA-SWARC > is not covered in the SAC process. I believe a more positive > thrust, whether or not it's accepted, is what's being desired here. > > > Maybe something more along the lines: > "During the review, concerns were expressed over the lack of > project alignment between SunRay and OpenSolaris. The > committee believes that this lack of alignment could, at least > partially, be mitigated by SunRay components being reviewed within > the OpenSolaris ARC process." > > Gary.. From sac-owner Wed Mar 25 12:45:45 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2PJjjOK023105 for ; Wed, 25 Mar 2009 12:45:45 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2PJji9t024939 for <@sunmail2sca.sfbay.sun.com:sac-review@sun.com>; Wed, 25 Mar 2009 12:45:44 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KH200I03UW8VJ00@nwk-avmta-1.sfbay.Sun.COM> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 12:45:44 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KH200IC8UW7GG00@nwk-avmta-1.sfbay.Sun.COM> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 12:45:43 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2PJjgiC022857; Wed, 25 Mar 2009 12:45:42 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id n2PJkQ1h020638; Wed, 25 Mar 2009 11:46:26 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id n2PJkQxw020637; Wed, 25 Mar 2009 12:46:26 -0700 (PDT) Date: Wed, 25 Mar 2009 12:46:26 -0700 (PDT) From: Gary Winiger Subject: Re: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio To: gww@eng.sun.com, John.Fischer@sun.com Cc: Phi.Tran@sun.com, james.d.carlson@sun.com, Alan.Coopersmith@sun.com, sac-review@sun.com Message-id: <200903251946.n2PJkQxw020637@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 529 > That works for me. Again, this is about getting more of the engineering > community to have visibility into the Sun Ray architecture. IMO, it's bi-directional. To be of greater benefit, SunRay engineering to have visibility into how to part of the OpenSolaris engineering community. Viz. Some of the SunRay engineering folk who shold have known said they hadn't heard of boomer until there was a comment made in another project I work with that was dealing with audio devices both on OpenSolaris and SunRay. Gary.. From sac-owner Wed Mar 25 13:00:36 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2PK0aja024073 for ; Wed, 25 Mar 2009 13:00:36 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2PK0U2Z010975 for <@sunmail2sca.sfbay.sun.com:sac-review@sun.com>; Wed, 25 Mar 2009 20:00:35 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KH200I0JVKW4L00@nwk-avmta-2.sfbay.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 13:00:32 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KH200B9WVKWOB90@nwk-avmta-2.sfbay.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 13:00:32 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2PK0WpW010393 for ; Wed, 25 Mar 2009 13:00:32 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KH200G00VGQGA00@fe-sfbay-09.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 13:00:32 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KH200KFCVKU5K60@fe-sfbay-09.sun.com>; Wed, 25 Mar 2009 13:00:31 -0700 (PDT) Date: Wed, 25 Mar 2009 13:00:30 -0700 From: "Garrett D'Amore" Subject: Re: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio In-reply-to: <49CA8840.4030204@sun.com> Sender: Garrett.Damore@sun.com To: John.Fischer@sun.com Cc: Gary Winiger , Phi.Tran@sun.com, james.d.carlson@sun.com, Alan.Coopersmith@sun.com, sac-review@sun.com Message-id: <49CA8D5E.8050604@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903251931.n2PJVjJP020574@marduk.eng.sun.com> <49CA8840.4030204@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1624 John Fischer wrote: > Gary, > > That works for me. Again, this is about getting more of the engineering > community to have visibility into the Sun Ray architecture. Works for me too. -- Garrett > > Thanks, > > John > > > Gary Winiger wrote: >>>> .... including having the appropriate Sun Ray components >>>> reviewed by >>>> the appropriate architectural committee and having IA-SWARC >>>> brought >>>> under the SAC umbrella. >>> better as: >>> >>> ... reviewed by the appropriate architectural committee under >>> SAC or, alternatively, by bringing IA-SWARC under the SAC >>> umbrella. >>> >>> I don't think anyone cares if they feel the need to run their own >>> ARC-like review process. No problem with that; perhaps more should do >>> likewise. The problem is when that ARC-like review is used in place >>> of SAC-sponsored open architectural review. >> >> SunRay have long felt exempt from the SAC process. Their design >> review is pretty formal -- and they call it IA-SWARC. >> I don't believe they need to be told yet again that IA-SWARC >> is not covered in the SAC process. I believe a more positive >> thrust, whether or not it's accepted, is what's being desired here. >> >> >> Maybe something more along the lines: >> "During the review, concerns were expressed over the lack of >> project alignment between SunRay and OpenSolaris. The >> committee believes that this lack of alignment could, at least >> partially, be mitigated by SunRay components being reviewed within >> the OpenSolaris ARC process." >> >> Gary.. > From sac-owner Wed Mar 25 13:14:05 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2PKE5Nj024451 for ; Wed, 25 Mar 2009 13:14:05 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2PKE26d002779 for <@sunmail2sca.sfbay.sun.com:sac-review@sun.com>; Wed, 25 Mar 2009 13:14:05 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KH200M1TW7FT800@brm-avmta-1.central.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 14:14:03 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KH200MTRW7D0J00@brm-avmta-1.central.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 14:14:01 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2PKE1Qf012204 for ; Wed, 25 Mar 2009 13:14:01 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KH200G00VGPG900@fe-sfbay-09.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 25 Mar 2009 13:14:01 -0700 (PDT) Received: from [10.1.48.53] ([unknown] [10.1.48.53]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KH200KA9W7C5KC0@fe-sfbay-09.sun.com>; Wed, 25 Mar 2009 13:14:00 -0700 (PDT) Date: Wed, 25 Mar 2009 13:14:03 -0700 From: Phi Tran Subject: Re: Opinion for review: PSARC/2008/318 Boomer: Next Generation Solaris Audio In-reply-to: <49CA8D5E.8050604@sun.com> Sender: Phi.Tran@sun.com To: "Garrett D'Amore" Cc: John.Fischer@sun.com, Gary Winiger , James.D.Carlson@sun.com, Alan.Coopersmith@sun.com, sac-review@sun.com Message-id: <49CA908B.6030909@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200903251931.n2PJVjJP020574@marduk.eng.sun.com> <49CA8840.4030204@sun.com> <49CA8D5E.8050604@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 1737 Garrett D'Amore wrote: > John Fischer wrote: >> Gary, >> >> That works for me. Again, this is about getting more of the engineering >> community to have visibility into the Sun Ray architecture. > > Works for me too. I'll make the changes. Thanks. Phi > -- Garrett >> >> Thanks, >> >> John >> >> >> Gary Winiger wrote: >>>>> .... including having the appropriate Sun Ray components >>>>> reviewed by >>>>> the appropriate architectural committee and having IA-SWARC >>>>> brought >>>>> under the SAC umbrella. >>>> better as: >>>> >>>> ... reviewed by the appropriate architectural committee under >>>> SAC or, alternatively, by bringing IA-SWARC under the SAC >>>> umbrella. >>>> >>>> I don't think anyone cares if they feel the need to run their own >>>> ARC-like review process. No problem with that; perhaps more should do >>>> likewise. The problem is when that ARC-like review is used in place >>>> of SAC-sponsored open architectural review. >>> >>> SunRay have long felt exempt from the SAC process. Their design >>> review is pretty formal -- and they call it IA-SWARC. >>> I don't believe they need to be told yet again that IA-SWARC >>> is not covered in the SAC process. I believe a more positive >>> thrust, whether or not it's accepted, is what's being desired here. >>> >>> >>> Maybe something more along the lines: >>> "During the review, concerns were expressed over the lack of >>> project alignment between SunRay and OpenSolaris. The >>> committee believes that this lack of alignment could, at least >>> partially, be mitigated by SunRay components being reviewed within >>> the OpenSolaris ARC process." >>> >>> Gary.. >> > From gdamore@Sun.COM Thu Mar 26 08:28:18 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2QFSINu011234 for ; Thu, 26 Mar 2009 08:28:18 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2QFS9AW060305 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 26 Mar 2009 09:28:17 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KH400H2BDN3TZ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 26 Mar 2009 08:28:15 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KH4008FPDN2P5D0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 26 Mar 2009 08:28:14 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2QFSE0k025769 for ; Thu, 26 Mar 2009 08:28:14 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KH400100DGWMM00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 26 Mar 2009 08:28:14 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KH4006PIDN0B2D0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 26 Mar 2009 08:28:13 -0700 (PDT) Date: Thu, 26 Mar 2009 08:28:12 -0700 From: "Garrett D'Amore" Subject: PSARC 2008/318: Boomer Next Generation Audio (update) Sender: Garrett.Damore@Sun.COM To: PSARC-ext Message-id: <49CB9F0C.2070308@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 953 I'd like to make the following minor updates to the case. 1) I forgot to list -b (balance) as one of the options that I'd like to remove from audioplay and audiorecord. Boomer implements "per application" volume as a monophonic value, so I'd like to handle this in the same way that we handle the port selection (-p). (I.e. we'll remove it.) Users can adjust master balance settings using mixerctl or gnome-volume-control. 2) I forgot to list the audiotest application in the exported interfaces table. It should be /usr/bin/audiotest Uncommitted This simply plays a test file on each of the possible audio channels (excluding, for the moment, the LFE channel. But that's a bug.) We don't support record or mixer testing yet. I can file a separate PSARC case if folks would rather deal with it that way, but it seems like these issues should be non-controversial enough to handle as a case update. Thanks. -- Garrett From sac-owner Fri Mar 27 09:20:44 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2RGKi9k027566 for ; Fri, 27 Mar 2009 09:20:44 -0700 (PDT) Received: from newsunmail1brm.central.sun.com (localhost [127.0.0.1]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2RGKhOX003062 for ; Fri, 27 Mar 2009 10:20:43 -0600 (MDT) Received: (from noaccess@localhost) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/Submit) id n2RGKhaa003060 for sac-opinion-not-2b-used-directly; Fri, 27 Mar 2009 10:20:43 -0600 (MDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2RGKfi8003013; Fri, 27 Mar 2009 10:20:43 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KH600J1BAQISK00@brm-avmta-1.central.sun.com>; Fri, 27 Mar 2009 10:20:42 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KH600DOXAQITE40@brm-avmta-1.central.sun.com>; Fri, 27 Mar 2009 10:20:42 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2RGKgHc025236; Fri, 27 Mar 2009 09:20:42 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KH600A00AHGG400@fe-sfbay-09.sun.com>; Fri, 27 Mar 2009 09:20:41 -0700 (PDT) Received: from [10.1.48.53] ([unknown] [10.1.48.53]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KH600HOHAOEEUC0@fe-sfbay-09.sun.com>; Fri, 27 Mar 2009 09:19:26 -0700 (PDT) Date: Fri, 27 Mar 2009 09:19:27 -0700 From: Phi Tran Subject: Opinion: PSARC/2008/318 Boomer: Next Generation Solaris Audio Sender: Phi.Tran@sun.com To: sac-opinion@sun.com Cc: sfsc-opinion@sun.com Message-id: <49CCFC8F.40202@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_xrek6AWBSpjrxAygrF3GZA)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 8816 This is a multi-part message in MIME format. --Boundary_(ID_xrek6AWBSpjrxAygrF3GZA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT The review for the opinion has been completed and the case is marked "closed approved". Phi --Boundary_(ID_xrek6AWBSpjrxAygrF3GZA) Content-type: text/plain; name=opinion.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=opinion.txt sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Boomer: Next Generation Audio Submitted by: Garrett D'Amore File: PSARC/2008/318/opinion.ms Date: March 5th, 2009 Committee: Garrett D'Amore (opinion written by Phi Tran), James D. Carlson, Mark Carlson, Rick Matthews, Sebastien Roy, Glenn Skinner. Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary Boomer: Next Generation Audio is a project to modernize the Solaris kernel-based audio system. The framework will be modernized to support the popular Open Sound System API used by several popular free operating systems, including Linux and FreeBSD. Audio quality will be improved by adding features such as high definition (both high frequency and high resolution sampling) and multichannel (for example, 7.1 surround sound) audio support. 2. Decision & Precedence Information The project is approved as specified in reference [1] - [3], but as modified by the required technical change listed in Appendix A below. The project may be delivered in a minor release of the ON consolidation. The project depends on the following other project and may not be delivered before it. LSARC/2009/074 EOF sdtaudiocontrol 3. Interfaces PSARC/2008/318 Copyright 2009 Sun Microsystems - 2 - The project exports the following interfaces. ______________________________________________________________________________ | Interfaces Exported | |______________________|_______________________|_____________________________| |Interface | Classification | Comments | |______________________|_______________________|_____________________________| |audio(7I) | Obsolete Committed | We've marked this API as | | | | Obsolete. We've also | | | | changed some semantics in | | | | ways that we believe are | | | | compatible. | | | | See the specification | | | | for more detail. | |mixer(7I) | See comments. | The old Sun mixer(7I) has | | | | been REMOVED. A new OSSv4 | | | | API is provided in its | | | | place with Uncommitted | | | | binding. | | | | See the specification for | | | | more detail. | |OSS API | Uncommitted | External userland API spec.| |/dev/sndstat | Uncommitted | Node for finding OSS dev | | | | nodes. | |/dev/audio | Obsolete Committed | Legacy Sun | |/dev/audioctl | Obsolete Committed | Legacy Sun | |/dev/sound/[0-9]+ | Obsolete Committed | Legacy Sun | |/dev/sound/[0-9]+ctl | Obsolete Committed | Legacy Sun | |/dev/mixer | Uncommitted | Symbolic link to | | | | /dev/sndstat | |/dev/dsp | Uncommitted | File name may change. | |Boomer DDI | Consolidation Private| New device driver API | |ac97 DDI | Consolidation Private| AC'97 support routines. | |SADA DDI | REMOVED | Legacy device driver API | |amsrc2 | REMOVED | | |mixer(7d) | REMOVED | | |audiosup(7d) | REMOVED | | |mixerctl(1) | Uncommitted | New CLI switches, may raise| | | | commitment later. | |audio control names | Uncommitted | ASCIIZ representation for | | | | hardware audio controls. | |audioplay -p & -m | REMOVED | Per TCA | |audiorecord -p & -m | REMOVED | Per TCA | |Client Personality API| Project Private | "audio_client.h" header. | |audiopci | Uncommitted | New audio driver. | |______________________|_______________________|_____________________________| 4. Opinion PSARC/2008/318 Copyright 2009 Sun Microsystems - 3 - 4.1. sdtaudiocontrol dependency A member wanted to understand if sdtaudiocontrol should be removed from Nevada before Boomer integration. The project team noted that LSARC/2009/074 EOF sdtaudiocontrol has been filed. In addition, LSARC/2009/074 is noted as a dependency for this case and the project team will file a bug. 4.2. digital telephone interface support A member questioned if Boomer could architecturally support digital telephone interfaces which are inherently 8-bit mu- law PCM (or A-law in Europe). The project team clarified that there is no support currently in Boomer to handle tele- phone inputs, but that Boomer could support these interfaces if there was a need. 4.3. audioplay and audiorecord command line options A member asked if the disabled command line options in audioplay and audiorecord will have an EOF announcement. Other members stated that having the functionality of the command line options available and not work properly was problematic. The project team noted that these command line options were still available due to concern over breaking programs that depend on them. The project team decided that this concern was not a strong enough reason and agreed to a TCR to make the EOF announcement regarding the command line options. Also, the project team agreed to a TCA to remove disabled command line options that handle port selection and master settings such as volume control and monitor gain. 4.4. audigy and SADA DDI Since the audigy driver will not be supported in phase I, a member asked about the support of the public SADA inter- faces. The project team clarified that the SADA interfaces are actually consolidation private and not public. 5. Minority Opinion(s) None. 6. Advisory Information During the review, concerns were expressed over the lack of project alignment between SunRay and OpenSolaris. The com- mittee believes that this lack of alignment could, at least partially, be mitigated by SunRay components being reviewed within the OpenSolaris ARC process. 7. Appendices PSARC/2008/318 Copyright 2009 Sun Microsystems - 4 - 7.1. Appendix A: Technical Changes Required 1. The project team will make an EOF announcement about disabled audioplay and audiorecord command line options. 7.2. Appendix B: Technical Changes Advised 1. The project team will remove disabled command line options that handle port selection and master settings such as volume control and monitor gain. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2008/318. 1. 20 Questions File: inception.materials/boomer.20q 2. Project Specification File: commitment.materials/boomer.pdf 3. Issues and Responses File: issues 4. Man Page for dsp OSS API File: commitment.materials/dsp.7I 5. Man Page for mixer OSS API File: commitment.materials/mixer.7I 6. Community OSS website http://developer.opensound.com/ PSARC/2008/318 Copyright 2009 Sun Microsystems --Boundary_(ID_xrek6AWBSpjrxAygrF3GZA)-- From gdamore@sun.com Mon Mar 30 08:29:35 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n2UFTZk4020246 for ; Mon, 30 Mar 2009 08:29:35 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2UFTVMV053607 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 30 Mar 2009 09:29:34 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KHB00803SD8X400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 30 Mar 2009 08:29:32 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KHB0064OSD8XM40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 30 Mar 2009 08:29:32 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2UFTWFE004622 for ; Mon, 30 Mar 2009 08:29:32 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KHB00L00RRP2K00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 30 Mar 2009 08:29:32 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KHB00E8TSD7TH00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 30 Mar 2009 08:29:32 -0700 (PDT) Date: Mon, 30 Mar 2009 08:29:31 -0700 From: "Garrett D'Amore" Subject: PSARC 2008/318 Boomer: Next Generation Solaris audio (small update) Sender: Garrett.Damore@sun.com To: PSARC-ext Message-id: <49D0E55B.6030400@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2493 As we've gotten nearer to integration, the project team has elected to change the audio DDK somewhat to eliminate inconsistencies and make it possible to fix a certain bugs. Since the changes only affect an unintegrated Consolidation Private interface, is relatively straight-forward, and since the team has fixed all of the interface consumers (which exist solely in the Boomer project gate), we believe this is best handled as an update to the case. The details of the changes: The engine interface has changed. Specifically: * audio_engine_alloc() no longer includes the engine format in its arguments * audio_engine_open() no longer includes the format, *nchan, or *rate in its arguments * audio_engine_rates() is removed. * new entry points for audio_engine_ops, audio_engine_format(), audio_engine_channels(), and audio_engine_rate() are mandatory * audio_engine_start() and audio_engine_stop() are now optional (possibly going to be removed in Boomer Phase II), and are only ever called in user or kernel context (resolves a problem for USB audio) The new entry points are trivial for most device drivers (most of them just return constant values like 48000 for the audio_engine_rate() or 2 for the audio_engine_channels(). Here are the prototypes for the functions: struct audio_engine_ops { int (*audio_engine_open)(void *, int flags, unsigned *fragfr, unsigned *nfrags, caddr_t *buf); ... /* * The following entry points return the currently configured * status of the engine. It is assumed that the engine's * configuration is relatively fixed, and does not change * while open, or in response to open. * * However, in the future we might like to allow for the * device to change the settings while it is not open, which * could allow for mixerctl to change the configured channels, * for example. In order to synchronize this properly, we'll * need the engine to perform a notification/request. That * will be added later. */ int (*audio_engine_format)(void *); int (*audio_engine_channels)(void *); int (*audio_engine_rate)(void *); ... } audio_engine_t *audio_engine_alloc(audio_engine_ops_t *, unsigned); If there are any questions or concerns about any of these changes, or if folks would like to see them more formally reviewed in a separate case, please let me know and I'll be happy to start a new fast track for them. -- Garrett