[Precise][Patch 0/2] ALSA: hda/realtek - Finer tuning of auto-parser with badness evaluation

[David Henningsson]

On 06/28/2012 07:24 PM, Herton Ronaldo Krzesinski wrote:
> On Thu, Jun 28, 2012 at 01:13:26PM -0300, Herton Ronaldo Krzesinski wrote:
>> The mixer in unpatched kernel misses HP Playback Volume, but in theory
>> Speaker Playback Volume should control the HP volume as well, since it
>> controls DAC nid 0x2 and headphone pin (0x21) is connected to 0x0c mixer
>> that gets the DAC 0x2 output.
>>
>> So, I'm wondering if the sound doesn't work in precise due to an user
>> space bug, may be the sound settings test, which I don't know as well
>> what it does exactly, may be is confused with missing/unexpected
>> headphone playback controls, or something else. The thing is, the
>> patches just make a different DAC to be selected for the Speaker pin 0x14,
>> which doesn't explain why the headphone test starting to work successfully,
>> so may be the test is not entirely right, or confused about the different
>> mixer items (may be a pulse issue related to "interpreting" the mixer).
>>
>> So may be trying to not use the sound settings test, pluging a headphone
>> and test by using another application or by passing pulse, may give a
>> better understanding. If it's confused about the mixer, may be ok, the
>> kernel change could be acceptable, but it means we have an diverged 3.2
>> realtek/alsa codec auto config parsing structural code which we would
>> need to always have to keep eyes on, not much practical.
>
> I forgot to check if automute had something to do with the bug, since in
> theory it could mute a DAC/mixer input if considering it for an entire
> pin class (like speakers vs. HP), so changing the DAC/mixer selection
> could have an influence.
>
> Checking now on the unpatched kernel, it seems to be doing nothing wrong.
> If you plug the headphone (pin 0x21), it mutes the speaker pins (changes
> the pin control to 0), no dac/mixer is touched:
>
>> jack 0x21 1
> send: NID=0x21, VERB=0xf09(get_pin_sense), PARM=0x0
> receive: 0x80000000
> send: NID=0x21, VERB=0x707(set_pin_ctl), PARM=0xc0
> send: NID=0x14, VERB=0x707(set_pin_ctl), PARM=0x0
> send: NID=0x1a, VERB=0x707(set_pin_ctl), PARM=0x0
> CTL Notify: Headphone Jack:0, mask=1
> JACK report Headphone, status 1
> JACK report Mic, status 0
>> jack 0x21 0
> send: NID=0x21, VERB=0xf09(get_pin_sense), PARM=0x0
> receive: 0x0
> send: NID=0x21, VERB=0x707(set_pin_ctl), PARM=0xc0
> send: NID=0x14, VERB=0x707(set_pin_ctl), PARM=0x40
> send: NID=0x1a, VERB=0x707(set_pin_ctl), PARM=0x40
> CTL Notify: Headphone Jack:0, mask=1
> JACK report Headphone, status 0
> JACK report Mic, status 0
>
> I'll follow up on the bug, hope didn't miss anything.

An idea could be to collect alsa-info from both a correct and a wrong 
kernel (both with headphones plugged in), and then diff them.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic