/dev/dump

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 t

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

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. Cirrus-Logic/Crystal CS 4281 -- driver is ready to go, stereo only FM-801 -- I think the driver will work, but don't have hardware at the moment to prove it. 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: Yamaha YMF-7 series -- driver not yet ready, but now I have hardware to work on it, if there is demand C-Media 8788 - driver mostly ready, but no

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.

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...)

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

Just a quick note.... we've discovered a problem where NWAM may not function if you have certain devices which use the "mii" module in build 123 of OpenSolaris. Hopefully the fix for this problem will be integrated today into build 124. The problem is that NWAM won't see your wired "interfaces" as down, and as a result, won't default to using wireless. Affected devices are afe, iprb, atge, dmfe and the yge beta test. The CR on this is CR 6880492. A webrev of the fix is available for the curious.

From the HEADS UP message: The push of CR 6878663 (PSARC 2009/384) introduces support for audio for certain Creative Sound Blaster Live! devices. If you have such a device, you can now enjoy audio playback and record support using your audio device. This driver includes 5.1 surround sound support. Devices supported are identifiable by the PCI id pci1102,6, and are Sound Blaster Live! models SB0200 and SB0213. They have a chip labeled "EMU10K1X" (note the "X") on them. These were primarily marketed as Dell OEM versions of the Sound Blaster Live! family. Enjoy!