[alsa-devel] [Alsa-user] Jetway j7f2 via82xx volume problem: sound suddenly stops when increasing volume: "SOLVED" (well ... sort of)

[Takashi Iwai]

At Tue, 29 Apr 2008 15:25:57 +0200,
Zoilo Gomez wrote:
> 
> >> This is consistent with the apparent introduction of this bug in kernel
> >> 2.6.19 (includes alsa-driver version 1.0.12rc1): no such problem
> >> occurred until 2.6.18, but all kernels since 2.6.19 do suffer from this
> >> problem. The line of code above first shows up in linux-2.6.19.
> >>
> >> Unfortunately, since I do not have a datasheet for the VT1617A chip set,
> >> I cannot verify the exact semantics, or suggest an improvement.
> >>
> >> Can anyone with a datasheet please suggest a proper patch to this line
> >> of code?
> >>     
> >
> > The register 0x5c is the VIA specific one.  I have a VT1617 (without
> > A) datasheet, and it suggests that the bit corresponds to the
> > "headphone amplifier temperature sensing control".  And setting this
> > bit means to _disable_ the temperature sensing control.  This sounds
> > rather the correct to set.
> >
> > However, I don't know whether any difference exists betweeen VIA1617
> > and 1617A although the codec id of both are identical.
> >
> > Andrey, any comments about your patch?
> >
> >
> > In anyway, it'd be helpful if we can know which ac97 registers work
> > and wich not.  Please take /proc/asound/card0/codec97#*/ac97#*-regs
> > file in both working and non-working cases to compare.  Especially,
> > the registers 0x5a and 0x5c look interesting.
> >   
> 
> Code containing "snd_ac97_write_cache(a97, 0x5c, 0x20)":
> 0x5a = 8300
> 0x5c = 0000
> 
> Code with "snd_ac97_write_cache(a97, 0x5c, 0x20)" commented out:
> 0x5a = 8301
> 0x5c = 0020
> 
> Quite a surprise to me, I would have expected exactly the opposite .....!?

I would, too.  Could you double-check, e.g. by adding a printk?
Also, any difference in other registers?

The reg 0x5a bit 0 is a reserved bits, so no further information about
it on VT1617 datasheet.

> Can you explain this? /proc/asound/card0/codec97#0/ac97#0-0+regs does 
> dump current registers, correct? Or is it a toggling bit?

It reads the current register values.  So, it's the value right now.
And snd_ac97_write_cache() should overwrite, not toggle.  The behavior
is really puzzling.


thanks,

Takashi