Friday, October 9, 2009

OpenSolaris on snv_124 Impressions

I've bitten the bullet, and finally installed "OpenSolaris" over my SXCE install, upgrading from build 105 to build 124 in the process. I thought I'd share some things I've noticed:

  • Gnome's volume control Just Works, and doesn't show the legacy Sun device anymore. (Yay!)
  • There is a 12 MB Core file on the CD ... er... too big... DVD ... image. (Oops!) Maybe someone was hoping the community would jointly debug the program that generated the core file. (gtk-update-icon).
  • Still no /bin/tcsh installed by default. Fortunately easy to get off the network for this machine. (For other systems, not so easy. This really ought to be fixed.)
  • AudioHD has a really, really annoying beep on this system. The beep volume control doesn't take effect until you lower it to 33%. (And then it gets really quiet.) This is a bug that I'll have to investigate further, there's probably some codec tweaking needed.
  • Regular SunOS vi has been replaced with vim, which has an incredibly obnoxious bug. It doesn't scroll down properly, redrawing on the last line in the terminal window instead of the whole screen. This is IMO at least a P2 bug against the editor. The old editor in SXCE, while maybe lacking some neat colorization features and not being open source, at least worked properly.
  • Trying to install CUPS using the package manager GUI fails with a horrible stack back trace. While the request is is made to report the problem with the stack back trace, there is no provision to save it or e-mail it. So alas, I don't have it anymore to post. It should be easily reproducible. (It looked like a problem relating to the SMF configuration.)
I have a lot more to do... so many things are at the moment still missing. But I think I'll be able to muddle on at this point. (The vim bug is going to really, really bug me though, because there isn't an easy workaround -- apart from just copying over the old vi from SXCE.)

Update: Turns out /usr/xpg4/bin/vi (which is what I had in my path anyway) doesn't have this problem. And its installed by default. Yay. But someone really needs to fix vim, because that bug is horrible.

Update 2: When I logged in using my old home dir, the Gnome panel which I had configured for auto_hide did hide itself. But unfortunately would not unhide itself with any mouse actions. The only way I could get it to unhide was to disable the auto_hide property using gconftool2. Unfortunately, it took a while to figure out how to use this.

Friday, September 25, 2009

Giving up on laptop-discuss@

Here's a message I sent to laptop-discuss-owner at opensolaris.org:

Okay, I've tried *three* different addresses to post to laptop-discuss@... each time the message bounces.

The addresses I tried:

gdamore@sun.com
garrett.damore@sun.com
garrett@damore.org

I give up. The list is *unusable* to community members, because of a draconian list policy that instead of just moderating reasonable attempts to post to the list just *bounces* them. This community (laptop-discuss@) will no longer be able to receive mail from me, despite the fact that I'm probably one of the more active contributors to the software that makes up core laptop platform support.

If you think your membership ought to be able to hear from me, then please make it easier for me (and for other people) who have a legitimate need to post to the list. Simple moderation with white and blacklisting can be used to achieve this.

- Garrett
For the record, the message I tried to post was:

I'm considering a case to remove/EOF the partial (incomplete) support we have for certain Tadpole laptops in Nevada.

I'd like feedback on this. Is anyone out there still using a Tadpole SPARCLE with OpenSolaris or Solaris Nevada?

The reason for this is the intention to remove support for graphics (its already not present in OpenSolaris). I never got enough cycles to finish the work to integrate power management or other mobility features for this platform (SPARCLE), and now it seems to be quite obsolete. We're talking about UltraSPARC-II (up to 650 MHz max cpu speed) systems here.

Would anyone here strongly object to just removing the support?

- Garrett
The bounce messages I received look like this:
You are not allowed to post to this mailing list, and your message has
been automatically rejected. If you think that your messages are
being rejected in error, contact the mailing list owner at
laptop-discuss-owner@opensolaris.org.

The problem is that draconian list membership/posting rules make posting updates incredibly painful. If you think my contributions to the forum are or would be useful, please ask the list moderator to start actually moderating the list instead of just setting it on auto-reject. (At this point, I don't remember which vanity address I subscribed to the list using... at the moment, I'm just about to the point of not caring. I've already reached this point with driver-discuss@ - on more than one occasion I've simply decided not to keep trying to send a message to that alias because of the same stupid draconian policy.

Thursday, September 24, 2009

why we might never support Dolby Digital

SPDIF (and AC3) are the (now legacy) ways that home theater systems are supposed to use to transfer high end surround sound to the receiver for amplification and distribution to individual speakers.

Many audio cards on the market can transport AC3 (aka Dolby Digital) or DTS compressed audio data over a digital cable (SPDIF). They can also transport 16-bit stereo PCM (uncompressed) to SPDIF.

Boomer can't decode or encode, or transcode, any compressed audio at the moment. While it might be nice if we could do this, there are significant and non-trivial hurdles to making that happen. Some are technical (such as computational costs and lack of hardware offload), and others are more legal (such as trademark, licensing, and patent considerations.)

So, Boomer could transport uncompressed 16-bit stereo over SPDIF. (That's all SPDIF has bandwidth for!) Which we support today in audiohd. And in the future we might extend this to other devices.

However some operating systems also support a pass-thru for compressed audio data, where data is taken from a source (such as a DVD application) and routed directly to the receiver without any changes. This works reasonably well, except that it adds a lot of complexity to make it work right, and you completely lose any control over gains or the ability to mix other audio sounds with the stream. (Want to get a notification of an incoming VoIP call while you are watching your movie? Too bad... you can't do that with AC3 passthru.) This mode is of such limited use that we're inclined not to support it at all -- its really only useful for media center PCs used in conjunction with home theater systems to watch DVDs. (And we already know about the various problems with watching commercial DVDs right? I won't talk about those legal problems here.)

The best feature for SPDIF is the ability to transfer 6 streams of data in a single cable -- using a lossy compression. The reduction in cables to tie this into your home theater system is really a good thing. But of course, we don't have an encoder, so we can't do that except in the pass-thru case we already said we weren't going to do. (So no 5.1 gaming via SPDIF for you... Dolby calls this Dolby Digital and all audio cards that support it do so in software only, which requires expensive licenses from Dolby.)

Fortunately, there are better options on the horizon, and this is where we want to spend our time.

One option is ADAT ("lightpipe") -- which can support 8 channels of uncompressed audio at 48 kHz. Its available on some motherboards even now. Supporting it would probably be fairly easy, although using ADAT might require some very high end audio equipment (ADAT is used in professional audio situations.)

A second, and far more accessible option, is the use of HDMI's audio channel. New motherboards (and some cards, such as the Asus Xonar HDAV) can support HDMI audio. HDMI supports 8 channels of uncompressed audio at up to 192 kHz. This is plenty for even the most demanding audiophile. And if you want more channels, you can always use a second HDMI cable! HDMI offers us the best audio capabilities without any compromises. (We can use it with mixing, volume controls, or use it in a bit-perfect fashion. We get full quality. And we don't have to deal with any of the licensing, technical, or legal headaches that accompany trying to get a real-time AC3 or DTS encoder working. ) So at this point, any investment spent in AC3 instead of HDMI on our part just looks kind of silly.

I expect that sometime later this year (or more likely next year), we will be looking hard at getting HDMI audio working with Boomer. (Note that I have no control over funding or project priorities -- so this is just a prediction, not a promise.)

audio driver enhancements

Okay, I've got some audio drivers that are basically ready to go, but which I'm trying to decide whether to integrate or not. Part of the problem is that integration of new drivers is a somewhat expensive process, and if there is no demand for some some of these, then I'd rather go do other things.

So, another straw poll. If you have one of these devices and you want a driver to test with, please let me know.

  1. Cirrus-Logic/Crystal CS 4281 -- driver is ready to go, stereo only
  2. FM-801 -- I think the driver will work, but don't have hardware at the moment to prove it.
  3. C-Media 8738/8768 surround sound support (stereo already supported in OpenSolaris) -- this will probably be integrated at some point, but I can share binaries now if someone wants them.

Other drivers I can supply with just a modicum of effort, if there is demand:

  1. Yamaha YMF-7 series -- driver not yet ready, but now I have hardware to work on it, if there is demand
  2. C-Media 8788 - driver mostly ready, but no hardware, and its expensive hardware to purchase.

Note that I will be doing the driver for the oft-requested EMU10K (Audigy/SB Live!) devices very very soon. Don't bother asking me again about it; its pretty high on my priority list. Likewise, X-Fi is very very desired, but will probably be quite a while longer in coming due to lack of specs. Various VIA chips (Envy24HT, etc.) are in the pipe as well.

And of course, Sun Ray audio is very high priority. Stay tuned for more on that.

Thursday, September 17, 2009

ohloh.net statistics

I notice that OpenSolaris has very few "users" listed on ohloh.net. Lets bump it up. If you use OpenSolaris, why not go ahead and create an account on ohloh.net, and indicate "I use this" for OpenSolaris.

While you're there, if you're grateful, you could grant kudos to your favorite developers. And if you have any contributions of your own (pushes to ON), go ahead and claim those to (search for your name or login in the "people")... it bumps your rank, and makes your "kudos" worth more when you deign to give them out.

Tuesday, September 15, 2009

ESS Solo-1 (audiosolo) integrated

I just integrated audiosolo -- it should be in build 125. :-) I think this driver might have set a new record for integration into ON. I started work on it Sunday afternoon, and integrated into ON on Tuesday evening. Proof that not all integrations into ON have to take forever. (Granted if this were NetBSD it probably would have integrated on Monday morning instead of tonight...)

Monday, September 14, 2009

Crazy Sunday -- ESS Solo-1

I got kind of bored on Sunday afternoon, and decided to do a port from FreeBSD of the driver for the ESS Solo-1 card. (I got one of these cards shipped to me by mistake from a vendor that didn't know the difference between different chips.)

It was getting late on Sunday, but I was almost ready to test. I resolved that when the system panic()'d, I'd call it a night and go get some sleep.

Amazingly, the system never panic()'d. I think this is the first time that I've brought up a new device driver (with a lot of new code!) without crashing the system at least once. (Usually its significantly more than that!) Hence, this may be the only device driver I know of that is both functional, and has never been the cause of a system crash.

Well, I wound up continuing to hack during testing -- never did make it to bed, and now its pretty much done. I'll post test binaries if someone else wants them. I still have to test suspend/resume and quiesce. There is also a bug where the record channels are swapped. This stumped me for several hours until I finally realized that my channel remapping facility in Boomer isn't supported for input channels, only for output (playback). Guess I'll have to go back and add that feature in to Boomer. (Its a small change, and now I've got a need for it.)

The driver is called "audiosolo", and will only be supported for x86 systems (the hardware can't address past the upper 24-bits of memory, so its useless on SPARC). Its only capable of 16-bit stereo record and playback, but these cards are apparently still sold as very low-cost budget add-in boards. (They are also found on some systems.) Look for ES1938 on the chip.

If you want the driver, let me know and I'll ship out some binaries. It will probably go into the next build or so, as I have time to get through the C-Team paperwork. I'm not meant to be working this during the "day job", as I have other priorities at present. But it might be a nice bonus for someone anyway. :-)