[alsa-devel] HDA - AD1986a issues.
tdavis at dsl-only.net
Mon Feb 4 17:38:10 CET 2008
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?
Better dead than mellow.
More information about the Alsa-devel