Sergei Steshenko wrote: > On Tue, 9 Jun 2009 23:09:45 -0400 > Lee Revell <rlrevell@xxxxxxxxxxx> wrote: > > >> On Sun, Jun 7, 2009 at 9:18 PM, Jamie Lokier<jamie@xxxxxxxxxxxxx> wrote: >> >>> But that doesn't explain why new kernels every few months behave so >>> differently on my Intel HDA laptop. >>> >>> >> Because a patch that makes sound work on one laptop can break sound on >> another laptop. Due to the design of HDA, the only way to guarantee >> this won't happen is to regression test each patch on every single >> make and model of PC on the market. >> >> > > Which just tells there should be one driver per motherboard/laptop, > and nothing will get broken. > > I.e. ALSA + kernle chose a wrong architecture, and specifically, kernel > developers chose a _very_ _wrong_ approach declaring their disregard of > stable binary API. > You're right in that having one HDA driver per motherboard/laptop would fix the issue, but do you really mean one distinct HDA driver for each of those hundreds of variants? And how do you distinguish them? In many cases, the particular sound device has the same pci id, but it's just wired up differently. And even if you keyed off some identifier gleaned from the BIOS then you're still down to a guessing game as manufacturers change the motherboard without changing the bit of the BIOS you were hoping to make the decision from. I don't see how the Linux ABI has anything to do with this. There is already a vehicle for manufacturers supplying drivers (or driver data) to the Linux community and a place to pop their drivers where they can be maintained. Lee is right: the design of hda means that the testing burden is huge. I'd add that the complexity also makes it impractical. > >> It's not even a good idea in theory. HDA was designed by Intel and >> Microsoft. The HDA "spec" allows so much variation from one model to >> the next that even on Windows, a vendor driver is usually needed to >> make sound work. In theory the BIOS is supposed to tell a generic >> driver how the audio is internally wired up on a given chipset. In >> practice vendors skip this step because it's cheaper to put that info >> in the .ini file of the vendor's Windows driver. >> > > Oh, so the info _does_ _exist_ in .ini file ?! And isn't the file a text > one ? And if so, can't it just be extracted from Windows driver CD or from > the manufacturer website, parsed, and the info used to make ALSA driver work ? > The info _might_ be in a .ini file, it might even be there in a way that can be understood without poring over the driver source code. On the other hand, it's even cheaper just to hard code the information into a driver. > >> It's almost as if HDA was designed to make sound support on non >> Microsoft OSes as difficult as possible. But we all know Microsoft >> would never do a thing like that ;-) >> >> > > Of course, Linux developers will never admit wrong approach - see the > comments above. Not that Microsoft and Intel are innocent, but still ... > Rubbish. Sorry, it's still rubbish. I've read that three times now and "Linux developers will never admit [the] wrong approach" is still rubbish. ALSA is at least the second generation approach to sound on LInux (I don't know if anything preceded OSS), if Linux developers never admited a wrong approach then ALSA wouldn't have arisen. I can't think of a kernel subsystem that hasn't undergone major upheavel because its previous incarnation proved to be a pile of poo. (I don't want to cast aspersions on anyone: generally the only good way to discover an approach is flawed is to try it and see what comes out.) I have to admit that the hda spec looks as though in the back of the minds of the people whose designed it that you could make it well nigh impossible to support devices for which the manufacturer didn't supply a driver. On the other hand, the hda hardware in the machines I've had is seriously lacking in quality and I'd much rather pay more money and go for something else, something that sounds nice. jch ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
