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

[Sergey 'Jin' Bostandzhyan]

Hi Takashi,

On Mon, Sep 02, 2019 at 08:41:48AM +0200, Takashi Iwai wrote:
> > Simpler...yes and no :) From what I have seen, all "default" Pulse profiles are
> > replaced by the UCM, meaning that if I wanted them, I'd have to replicate
> > all of them in my conf. It would work though. 
> 
> You just need to override codec->card->longname to some unique string
> and use it as UCM profile name.
> Check alc1220_fixup_gb_dual_codecs() as an example.

no, no, that's not what I meant. I did understand how to tell PulseAudio
which UCM to load, i.e. via the longname just as you wrote above.

However, what I then observed was: PulseAudio loads my UCM configuration and
pavucontrol lists only the profiles which I have specified in the UCM.

So what I was trying to say is that I lose all the stock profiles that
PulseAudio creates automatically and that list is quite long (i.e. 
Analog Surround 5.1 Output + Analog Stereo Input, same for 5.0, 4.1, 4.0 and
so on), basically the stock profiles get dropped in favor of the ones that I 
provide in the UCM.
 
> > Meanwhile I also figured out that /proc/asound/card0/codec#0 is
> > providing this info as well:
> > 
> >   IO[1]: enable=0, dir=1, wake=0, sticky=0, data=0, unsol=0
> > 
> > So the value seems to be 0 and I can add an explicit SET_GPIO_DATA verb quirk
> > to set it in addition to SET_GPIO_DIRECTION, right?
> 
> Yes.  You need to set SET_GPIO_MASK=0x02, SET_GPIO_DIRECTION=0x02 and
> SET_GPIO_DATA=0x00 for that bit.

Thanks a lot, I read the hda-intel spec on GPIOs a couple of times, but I
was somehow not getting the idea about the GPIO MASK, now it's clear what
I was missing. I'll add those three verbs to my quirk.

[...] 
> > The above seems to work quite well for me and does exactly what I want, 
> > PulseAudio presents all the autogenerated profiles and handles mic and line 
> > jacks itself, at the same time all unwanted speakers get muted as soon as I 
> > plug in my headphones into the jack pin that is shared with my surround
> > speakers. Of course Pulse does not "know" anything about the headphones and
> > does not switch profiles, but I don't mind since the user experience is
> > as expected.
> 
> Hm, OK, this amount of changes are acceptable.  The hardware behavior
> itself is weird, and we have already tricky code, so it's no problem
> to keep some yet another tricky code as long as it's described enough
> in the comments and the changelog.

Great, thank you! I will prepare a patch then, I like this approach a lot
more than the UCM variant.
 
> > My earlier attempt was to send the pin widget control verbs directly, however
> > then the pin got reconnected as soon as playback started.
> > This does not happen when I use snd_hda_set_pin_ctl_cache(), but I am not 
> > quite sure about the cache, should I use the _cache function or the
> > uncached one?
> 
> This should work, AFAIK.  The *_set_pin_ctl_cache() remembers the last
> written value, as its name stands.  That's restored again at the PM
> resume, for example.
> 
> The PM resume does re-trigger the jack detection callback, so it'll be
> written up again in anyway, though.

Thanks for the explanation, seems I picked the right function.
 
> > Another thing I am not sure about is, if I somehow disrupt power management by 
> > doing what I do? I saw that for instance restore_shutup_pins() does modify 
> > those connections as well and I would basically overwrite whatever it did
> > in the case that the user plugs/unplugs the headphones.
> 
> This should be fine as-is.  The shutup_pins() clears pins temporarily
> and the pins are resumed to the cached values in return.

I was more thinking of the scenario that shutup_pins() cleared them,
some time afterwards the user unplugs headphones which triggers my jack-detect 
callback where I reconnect the pins, although the "shutup" condition is still
valid. Maybe I'm overthinking it. If this is not a problem, then I'm indeed
almost done - easier than I thought :)
 
> One thing to be improved would be to drop the surround jack control.
> Adjust the pin config to different value with the fixed pin
> connection, so that the auto-parser won't create the "Surround Jack"
> control.  This isn't needed by PA or else, otherwise it may be
> confusing.

Hmm, if I understand you correctly, then you are referring to bits 31:30
Port Connectivity? 

It does not seem to work that way... I tried all combinations and I either
lose jack detect support or I lose the 5.1 profile in Pulse.

With these settings snd_hda_jack_detect_state() never returns HDA_JACK_PRESENT:
0x91130012 [Fixed] Speaker at Int Rear
0xd1130012 [Both] Speaker at Int Rear

I can plug or unplug, I get called, but I always receive HDA_JACK_PHANTOM

snd_hda_jack_detect_state() works fine with "no physical connection to port":
0x51130012 [N/A] Speaker at Int Rear

But with the above pin setting I "lose" the 5.1 profile in Pulse...

Which leaves me with with what I had before:
0x11130012 [Jack] Speaker at Int Rear

Am I missing something or did you mean some other setting? Should I be
using a different function instead of snd_hda_jack_detect_state() to
check my jack state in the callback?


I will study the kernelnewbies howto a bit more  (it's my first
kernel patch submissoin) and will follow up with a patch soon.

Thank you very much for your help! I would not have come so far
without your support, really happy that my audio finally works :)

Kind regards,
Jin