On Mon, 2008-02-04 at 16:19 +0100, Takashi Iwai wrote: > At Fri, 01 Feb 2008 14:57:35 -0800, > Tobin Davis wrote: > > > > On Fri, 2008-02-01 at 16:13 +0100, Takashi Iwai wrote: > > > > > Also, I had some very strange audio garbage with the tip on an HD Audio > > platform > > > that normally works ok. I'm going to be tracking it down this morning, > > once I > > > get to work (1 hour). I'm not sure if it is related to the AD1986a or the > > SCH > > > (gcap patch). > > > > AD1986A has a known problem when you assign the single stream to > > multiple DACs. But, we should have fixed this already in 1.0.16rc2. > > > > Ok, I can confirm on my test system that the HDA-GCAP and HDA-SCH patches are > > ok. I tested them on 1.0.15 with an AD1986a and they work fine. Same system > > with HG20080130 is aweful. I'm trying to revert the patch_analog patches one at > > a time to see which one is the problem. > > Did you find out the problem? I vaguely remember that EAPD may play a > bad role for headphones. This should be disabled except for the > speaker output. The problem I noticed only occurred on my SCH based system. It was solved with the snoop bit check/set. I'll double check to see if I have any issues on my laptop (Asus Z62F w/ ad1986a - model=laptop-eapd). Oddly enough, the system worked fine with 1.0.15 and the two earlier patches (GCAP and SCH PCI IDS). Not sure what to make of that. I'll do more testing today. > > > > I do know that GCAP returns 2200 on this system, whereas a normal > > > ICH returns 4401. The last bit may be significant (64bit vs 32bit > > stream). I > > > need to reverify the SCH value, but this may be causing the issue. This > > is > > > critical for a launch coming up. > > > > Hm, this bit hasn't been tested. OK, we need a fix for that. > > > > No need to worry about this bit I guess. It may only be relevant on a system > > that runs 64bit OSes, and I'd assume that bit doesn't exist for systems that > > can't. > > The fix itself would be pretty easy. Check this bit and reset the dma > consistent mask to 32bit if it's 32bit only. > > Hm, this reminds me that we should call set_mask with 64bit as > default. Needs more investigation... Is this dependent on system/OS? My thought was it was for supporting x86-64 architecture. That being the case, it should be added to the TODO list, but not critical for 1.0.16 release. Actually, there are other potential issues that I noticed with regards to GCAP and our current usage. For example, bi-directional stream support and number of serial data out signals. Both are hardwired in the ICH family of chipsets, but for how long? -- Tobin Davis Better dead than mellow. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
