[alsa-devel] regression: from 3.8 to 3.9: headphones output no sound on Intel HDA, codec VIA VT1802

Takashi Iwai tiwai at suse.de
Fri May 24 19:22:53 CEST 2013

At Fri, 24 May 2013 18:36:14 +0200,
Alex Riesen wrote:
> On Fri, May 24, 2013 at 3:29 PM, Takashi Iwai <tiwai at suse.de> wrote:
> >> On Fri, May 17, 2013 at 8:04 AM, Takashi Iwai <tiwai at suse.de> wrote:
> >> >> Well... It seems that something went unnoticed. This command seems
> >> >> to be essential for this (and the revised) patch to get the headphone
> >> >> output at all:
> >> >>
> >> >>         hda-verb /dev/snd/hwC0D0 0x25 SET_PIN_WID 0xc0
> >> >
> >
> > Looking at the outputs above, it seems that turning on/off EAPD on VT
> > codecs triggers the automatic power up/down of the pin, which leads to
> > the unexpected result.
> I may be wrong here, but why the patch touches EAPD handling, but not WID?

Well, I assumed that the EAPD off triggers the pin widget off by the
hardware, too.  But it seems wrong.  By some reason, the hardware
clears the pin automatically.  Hmm.

Could you try to trace the verbs while plugging the headphone?
Check whether you have /sys/kernel/debug/tracing directory.  If not,
make sure that you enabled the kernel tracing capability.

Then, just before plugging the headphone, run below:

  # echo 1 > /sys/kernel/debug/tracing/events/hda/enable

This will start the logging HD-audio verbs.  Then plug the headphone,
and get the trace via

  # cat /sys/kernel/debug/tracing/trace > trace.log

then disable tracing again

  # echo 0 > /sys/kernel/debug/tracing/events/hda/enable

And attach trace.log.  Then we can see whether the driver touches the
pin widget at all.

> > Could you try the patch below?
> I did, it does not work. Transcript and alsa-info before and after
> hda-verb attached.

OK, I'll cook up the new patch later.



More information about the Alsa-devel mailing list