[alsa-devel] Spectre x360 fixing the top speakers (again)

[Alex G.]

On 08/05/2018 11:57 AM, Takashi Iwai wrote:
> On Sun, 05 Aug 2018 18:28:57 +0200,
>   Alex G.  wrote:
>>
>> It's only been since 4.18-rc2 that the speaker issue on the x360 [1]
>> was resolved. I didn't even know I had four speakers until seeing that
>> bug report. My HP Spectre x360 (13-ae0xx) has the same issue as the
>> original x360 with Bang speakers.
>>
>> The subsystem PCI ID is different [103c:83b9]. Of the two fixes
>> developed in [1], only the mute led fix works when the PCI id is added
>> to patch-realtek. If I try to add the full ALC295_FIXUP_HP_X360 fix,
>> there's no audio coming out at all.
>>
>> One thing I tried was to boot W10 virtual machine and redirect the
>> audio PCI device to the VM:
>> 0:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)
>> It all worked in the VM, but as soon as I shut it down and tried to
>> play audio from linux, the top speakers still didn't work. The
>> difference being that PAVUcontrol could see a "4.0 output"
>> configuration. The same issue: audio sent to the bottom speakers was
>> heard, but audio sent to the top speakers was not.
>>
>> Since I'm likely going to have to change _everything_ anyway, here's
>> what I'm trying to achieve:
>>
>>
>> 1) Make the top speakers great again. Whether they produce the same
>> sound as the bottom speakers, or have their own audio channel, I don't
>> care that much.
> 
> Well, "again" -- you have never got it working on Linux, right?

"Again" in the sense that HP f'd it up again, the same way they did with 
the original x360. And I say f'd instead of messed up, because even in 
windows, two outputs show up, but only one of them produces any sound 
(out of all four speakers).

> The top speaker thing is likely the missing initialization of I2S amp,
> EQ or DRC, which seem to be done via vendor-specific COEF verbs.

I2S amp? I was under the impression the codec has a DAC for that. This 
isn't really making much sense.

> The Windows VM work just because these initializations are done in
> Windows side.  You'd need to get these init verbs, but it's a tough
> issue.  The best would be to get the proper data from the vendor.
> Unfortunately HP seems have zero interest in supporting the device on
> Linux at all.  Luckily we've got the data kindly from Realtek at the
> previous time for one x360 model after Tom's great effort.

If the VM configures the magic to a working state, shouldn't it stay 
working after the VM is killed and linux takes over? I don't see 
anything to to de-init the work the windows driver has done.

> Hopefully Kailang (Cc'ed here) may ask his colleagues and get some
> info...
> 
> 
>> 2) Be able to use the speakers when something is plugged in the
>> headphone jack. Right now it's stupid. I try to plug in a microphone
>> (with the proper TRRS jack), and the speakers die. I haven't seen this
>> before. I was playing with HDA-Analyzer and was able to get speaker
>> sounds with a dummy plugged in the jack, so I know it's possible. I
>> don't remember how I did it, and it only worked once.
> 
> The TRRS handling is again very much vendor-specific, and most likely
> one of the existing methods may fit.  Check the headset-related
> helpers and callbacks in patch_realtek.c.

Ah. I was hoping it might be as simple as figuring out how to drive the 
EAPD lines. I did have this somewhat working messing around with 
HDA-analyzer, but... and here's the rub... I haven't found a consistent 
way to do it.

Alex

> Takashi
> 
>> 3) (optional) see if there's a way to use the jack as a line in or
>> stereo mic in.
>>
>> I'm not sure where to start.
>>
>> Alex
>>
>> [1] https://bugzilla.kernel.org/show_bug.cgi?id=189331
>>