Message ID | 20120628161325.GA3314@herton-Z68MA-D2H-B3 |
---|---|
State | New |
Headers | show |
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.
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.
--- codec_unpatched.txt 2012-06-28 11:32:27.922394741 -0300 +++ codec_patched.txt 2012-06-28 11:36:38.582398025 -0300 @@ -15,7 +15,7 @@ GPIO: io=2, o=0, i=0, unsolicited=1, wak IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 Node 0x02 [Audio Output] wcaps 0x1d: Stereo Amp-Out - Control: name="Speaker Playback Volume", index=0, device=0 + Control: name="Headphone Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Device: name="ALC269VB Analog", type="Audio", device=0 Amp-Out caps: ofs=0x57, nsteps=0x57, stepsize=0x02, mute=0 @@ -26,8 +26,6 @@ Node 0x02 [Audio Output] wcaps 0x1d: Ste bits [0xe]: 16 20 24 formats [0x1]: PCM Node 0x03 [Audio Output] wcaps 0x1d: Stereo Amp-Out - Control: name="Bass Speaker Playback Volume", index=0, device=0 - ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x57, nsteps=0x57, stepsize=0x02, mute=0 Amp-Out vals: [0x00 0x00] Converter: stream=0, channel=0 @@ -116,8 +114,6 @@ Node 0x12 [Pin Complex] wcaps 0x40000b: Pin-ctls: 0x20: IN Node 0x13 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x14 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out - Control: name="Speaker Playback Switch", index=0, device=0 - ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x00010014: OUT EAPD Detect @@ -129,7 +125,7 @@ Node 0x14 [Pin Complex] wcaps 0x40018d: Pin-ctls: 0x40: OUT Unsolicited: tag=00, enabled=0 Connection: 2 - 0x0c* 0x0d + 0x0c 0x0d* Node 0x15 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x16 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x17 [Pin Complex] wcaps 0x40010c: Mono Amp-Out @@ -172,8 +168,6 @@ Node 0x19 [Pin Complex] wcaps 0x40008b: Pin-ctls: 0x20: IN VREF_HIZ Unsolicited: tag=00, enabled=0 Node 0x1a [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out - Control: name="Bass Speaker Playback Switch", index=0, device=0 - ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x2f, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1