[alsa-devel] Surround speaker connection on Acer 8951G

Thu Aug 29 13:29:13 CEST 2019

On Thu, 29 Aug 2019 12:38:05 +0200,
Sergey 'Jin' Bostandzhyan wrote:
> 
> Hi Takashi,
> 
> On Thu, Aug 29, 2019 at 11:30:45AM +0200, Takashi Iwai wrote:
> > On Thu, 22 Aug 2019 22:30:31 +0200,
> > Sergey 'Jin' Bostandzhyan wrote:
> > > 
> > > Next thing I am looking at is the problem with automute when HP are plugged in,
> > > I hope you can point me in the right direction here.
> > > 
> > > As described in one of my earlier posts, rear speakers share the pin with 
> > > the headphones jack and they get correctly muted when headphones are plugged in.
> > > 
> > > However, all other speakers (front, center) remain unmuted.
> > 
> > That's an ugly situation, and currently no clean way to deal with such
> > a shared pin for outputs, unfortunately.  The auto-parser can handle
> > the case with input/output switching (e.g. sharing mic and surround),
> > but not about the two outputs.
> > 
> > One possible way with the current code (and your latest patch) would
> > be to create a UCM profile.  The driver should still provide the jack
> > detection on the pin 0x1b as "Surround Jack", and this can be used as
> > the headphone jack detection.
> 
> I gogled it up and I did find HDAudio-Gigabyte-ALC1220DualCodecs as an
> example, so basically the solution in this case would be split between
> the driver and alsa-lib?

Right.

> Are there any disadvantages to muting the other channels directly in the
> driver? Or would it be a viable option to extend the auto-parser to
> handle the remaining channels?

It's not so trivial to extend.  The logic of driver parser assumes the
single purpose pins, and if they appear doubly, the behavior becomes
confusing.  For example, if you just add the same pin to both
speaker_pins[] and hp_pins[], all speaker_pins[] get muted by the
auto-mute, hence you'll mute the headphone again.  OTOH, if you don't
list up the pin in speaker_pins[], it won't be used for speakers for
multi-channels, obviously.

> Personally, I would prefer a solution at one place, but I follow your lead here,
> if you say that UCM is the way to go, then so be it.

We can give it a try.  If it doesn't work as expected, we'd need more
extension in the driver side.

> I played around with jack detection and I had the feeling that it did not work
> reliably, or maybe I misunderstood something?
> 
> Who is responsible for setting spec->gen.hp_jack_present? I thought that
> this variable always represents the current presence state of the hp jack?
> 
> I tried printing it from my automute hook, but it never changed. My assumption
> is, that due to 0x1b's pin configuration its not treated by the driver
> as an hp_out, its also not added the hp_outs array.
> 
> I tried to add the pin to the hp_outs array manually, but I could not
> see any difference.
> 
> In the end I configured the 0x1b pin to allow jack sensing, but I noticed that
> the hook will not get triggered during playback, is this a bug or am I missing 
> something?
> 
> I tried the following:
> 
> static void alc662_aspire_ethos_hp_automute_hook(struct hda_codec *codec,
>                      struct hda_jack_callback *jack)
> {
>     struct alc_spec *spec = codec->spec;
>     unsigned int hp_jack_old_state = spec->gen.hp_jack_present;
> 
>     if (snd_hda_jack_detect(codec, 0x1b) == HDA_JACK_PRESENT) {
>         printk("HP AUTOMUTE HOOK: hp plugged in\n");
>         spec->gen.hp_jack_present = 1;
>     } else {
>         printk("HP AUTOMUTE HOOK: hp unplugged\n");
>         spec->gen.hp_jack_present = 0;
>     }
>     if (hp_jack_old_state != spec->gen.hp_jack_present) {
>         printk("Detected state change on pin 0x1b, jack present: %d\n",
>             spec->gen.hp_jack_present);
>     }
> }
> 
> I kept watching dmesg, when nothing is playing the plugged in/unplugged
> messages appear correctly, but if I start speaker test and replug during
> the playback, nothing is printed.

Check rather "Speaker Surround Jack" state upon plugging the
headphone.  Does it change reliably?

Note that even if you set such flags manually like the above, it won't
work, because of the reasons I already mentioned.

> Meanwhile I made progress on the LFE topic:
> >> Could someone hint me how to proceed in "finding the LFE"? Where should I be
> >> digging? I did also have a look at parser hints documentation and tried some,
> >> but this was more a random attempt and did not really help me.
> >
> > It might be some other external stuff like an external amp that is
> > missing.  Often it's managed via GPIO or EAPD (that is controlled by
> > HD-audio itself), but sometimes via a vendor-specific verb, or even
> > over a completely different i2c...
> >
> > In the case of vendor verbs, you can take a look at other quirks for
> > similar models that touches lots of COEF stuff.
> 
> Turned out it was indeed a GPIO, I won't describe all the things I tried, in the
> end it was a lucky click on the dir_out checkbox in hda-analyzer while I was
> debugging the shared pin issue :)
> 
> The below HDA_FIXUP_VERBS does the trick, so I do have all 6 speakers working, 
> finally!
> 
> {0x01, AC_VERB_SET_GPIO_DIRECTION, 0x02}

Actually this must be paired with the corresponding bit of GPIO_DATA,
too.  Is the bit 0x02 of GPIO_DATA set or cleared?  Usually setting it
turns on the amp, but sometimes inverted.

> The only thing that is not quite clear to me is - does LFE still have its
> own pin and I was just not able to find it, but managed to unmute it via
> the GPIO? Or is the LFE speaker somehow "intenrally managed"? It works
> correctly though, alsa mixer is also capable of controlling LFE volume
> separately so it's fine, everything is also working with pulseaudio and a 5.1
> profile on top.

It's usually just the external amp controlled via GPIO, and the signal
must go through the pin 0x18 as well as the center channel, I suppose.

Takashi

> 
> So right now muting seems to be indeed the last remaining piece of the puzzle.
> 
> > In anyway, could you give alsa-info.sh outputs with and without your
> > patch?
> 
> Here is the original output of the unmodified system:
> http://alsa-project.org/db/?f=3adde87164f5fc349c3c78b211ee63e416ebf10b
> 
> Here is my current state:
> http://alsa-project.org/db/?f=5f1c8730d3099099b4c7442cb09d475e5618c3c6
> 
> I also pushed my code to github:
> https://github.com/jin-eld/hda-intel-alc669x
> 
> Thank you very much for not giving up on me :) Your feedback is very valuable!