Fred Langa, CC: Triangle Linux Users Group I read and enjoyed your efforts to get sound working on Linux with mainstream Intel hardware. Particularly, where you could go all the way back to Win95. Your intrepid efforts are valiant, and demonstrate great skill in diagnosis and problem solving.
A possiblity exists that Intel never tested new revisions of this mainboard/sound processor combination with Linux, yet still intend to provide (limited) compatiblity. But, based on the results of your thorough testing, I doubt that this is the case. LOADLIN has been used for several years to conquer the specific sound card problem you've encountered. Loadlin is a windows based utility that allows users to boot (or springboard) Linux once WINxx is up and running. This problem boils down to the single issue of closed interface architectures versus open interface architectures. The Intel integrated sound system on your computer is a programmable device, perhaps (and very likely) it is "Sound Blaster Compatible"; yet still it is a closed-technology Intel-proprietary device. It may well never be "Linux supported" directly from _within_ the Linux community, because it would be a violation of license agreements to do so. At a minimum, it would be a violation of Intel's copyright protection over thier sound card chip(s/set) for a Linux kernel contributor to reverse-engineer the binary object code that is downloaded into this device without formal approval from Intel. Only Intel can provide a solution. They must contribute an open source module which downloads the binary code to the chip. Clearly, Intel has decided not to follow this path, prefering to protect their sound system through mantaining trade secrecy in their technology. Any other choice on Intel's part could be a potential compromise of their proprietary technology. So it is quite justifiable and well within Intel's rights to protect their intellectual property. Here is your key question: "And if the hardware was to blame, how could XP handle it out of the box, with no special drivers or setup?" And the key answer is, of course, that hardware vendors write their proprietary drivers and provide the code directly to Microsoft. These drivers provide the interface between the OS and the layers of abstraction (Hardware Abstraction Layer) see http://hal.freedesktop.org/ for a description of the nascent efforts in this arena) Based on a quick skim of your recent article on Microsoft's Virtual PC product, it comes to me as no surprise that it would not solve your sound card interface problem. The abstraction layer would be no different, would it? So here is how Loadlin solves the problem: 1 - Boot into Windows. 2 - Windows downloads the proprietary code into the sound device(s) a - e.g., perhaps Digital Signal Processor (DSP) microcode, b - e.g., and some SoundBlaster emulation mode interface routines C - Run Loadlin. Loadlin starts up Linux D - Linux probes hardware, and sees what looks like a sound-blaster/compatible interface. E - Sound works under Linux as expected. As an aside, in the SCSI disk adapter world, similar issues used to arise in Mylex versus Adaptec. Mylex opened their interfaces many years ago, making it much easier to design, test, probe and integrate their products. At that time, it provided Mylex with a distinct competitive advantage over Adaptec in the Linux server world. In summary: (1) Caveat Emptor. (2) Apparently Intel Inside doesn't necessarily indicate open architecture compatibility. (3) Look for the Linux friendly Tux the Penguin on your retail packaging. Respectfully, Marty Ferguson, RHCE, RHCX, LPI-1 Certified -- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/ TriLUG PGP Keyring : http://trilug.org/~chrish/trilug.asc
