[alsa-devel] Internal Mic Boost channel is unused
Hello,
I have an issue I'd like to help completely solve. Unfortunately I only have a tenuous grasp of what is actually going on so some of this could be wrong/include errors.
Here's what I know.
1) I have the following hardware (alsa-info attached). 2) The internal microphone requires that the mic boost channel be something other than 0 to function properly. 3) Changing what pulseaudio expects things to be labelled causes the problem to go away. (via the attached patch to /usr/share/pulseaudio/paths/analog-input-mic.conf).
From the discussion with David Henningsson (diwic on IRC). It seems that pulse doesn't expect a Mic Boost channel to be used with internal microphones. As such to fix this particular hardware, the driver would need to make the internal mic boost be labelled "Internal Mic Boost" as opposed to Mic Boost, which is then is used for both external and internal mics.
I'd love to be able to help any way I can to get these fixed once and for all. Let me know if you need more information or what not.
On tor, 2013-09-12 at 09:52 -0600, Nathanael D. Noblet wrote:
Hello,
I have an issue I'd like to help completely solve. Unfortunately Ionly have a tenuous grasp of what is actually going on so some of this could be wrong/include errors.
Here's what I know.
- I have the following hardware (alsa-info attached).
- The internal microphone requires that the mic boost channel be
something other than 0 to function properly. 3) Changing what pulseaudio expects things to be labelled causes the problem to go away. (via the attached patch to /usr/share/pulseaudio/paths/analog-input-mic.conf).
From the discussion with David Henningsson (diwic on IRC). It seems that pulse doesn't expect a Mic Boost channel to be used with internal microphones. As such to fix this particular hardware, the driver would need to make the internal mic boost be labelled "Internal Mic Boost" as opposed to Mic Boost, which is then is used for both external and internal mics.
I'd love to be able to help any way I can to get these fixed once and for all. Let me know if you need more information or what not.
So I saw that you had two selector nodes (0x17 and 0x18), so I figured one could be "Internal Mic Boost" (for internal mic) and the other one "Mic Boost" (for external mic).
However, according to the BIOS, you actually have *two* external mic jacks. Is this correct? It could possibly be that one of them is part of a headset jack. This might be related to what's confusing the driver, so perhaps if we just removed the fake mic input that would make things work.
// David
On 09/12/2013 12:43 PM, David Henningsson wrote:
So I saw that you had two selector nodes (0x17 and 0x18), so I figured one could be "Internal Mic Boost" (for internal mic) and the other one "Mic Boost" (for external mic).
However, according to the BIOS, you actually have *two* external mic jacks. Is this correct? It could possibly be that one of them is part of a headset jack. This might be related to what's confusing the driver, so perhaps if we just removed the fake mic input that would make things work.
I do have two external mini jacks. One has a mic image, one has a headphone image... Whether both can be used as mic inputs that I'm not sure about.
- I have the following hardware (alsa-info attached).
Simple mixer control 'Input Source',0 Capabilities: cenum Items: 'Mic' 'Internal Mic' 'Mic 1' Item0: 'Internal Mic' Simple mixer control 'Input Source',1 Capabilities: cenum Items: 'Mic' 'Internal Mic' 'Mic 1' Item0: 'Internal Mic' Simple mixer control 'Input Source',2 Capabilities: cenum Items: 'Mic' 'Internal Mic' 'Mic 1' Item0: 'Internal Mic'
using hda-emu
the driver always use selector 0x17 for the three input source controls
6 Input Source:0 ITEM: 0:Mic, 1:Mic 1, 2:Internal Mic, VAL: [Mic]
set 6 2
send: NID=0x14, VERB=0x701(set_connect_sel), PARM=0x0 receive: 0x0 send: NID=0x17, VERB=0x701(set_connect_sel), PARM=0x3 receive: 0x0
set 7 2
send: NID=0x15, VERB=0x701(set_connect_sel), PARM=0x0 receive: 0x0 send: NID=0x17, VERB=0x701(set_connect_sel), PARM=0x3 receive: 0x0
set 8 2
send: NID=0x16, VERB=0x701(set_connect_sel), PARM=0x0 receive: 0x0 send: NID=0x17, VERB=0x701(set_connect_sel), PARM=0x3 receive: 0x0
It is a bug of the driver to create three input source select controls when there are only two audio selectors 0x17 and 0x18 as node 0x23 is not one of the input pins
The topology does not allow three different input sources with two selectors
- The internal microphone requires that the mic boost channel be
something other than 0 to function properly.
You have to find out whether node 0x1a or 0x1b can be used as the headset jack (headphone with Mic using TRRS connector)
- Changing what pulseaudio expects things to be labelled causes the
problem to go away. (via the attached patch to /usr/share/pulseaudio/paths/analog-input-mic.conf).
From the discussion with David Henningsson (diwic on IRC). It seems
that pulse doesn't expect a Mic Boost channel to be used with internal microphones. As such to fix this particular hardware, the driver would need to make the internal mic boost be labelled "Internal Mic Boost" as opposed to Mic Boost, which is then is used for both external and internal mics.
Node 0x14 [Audio Input] wcaps 0x100d1b: Stereo Amp-In R/L Control: name="Capture Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Capture Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Device: name="CX20588 Analog", type="Audio", device=0 Amp-In caps: ofs=0x4a, nsteps=0x50, stepsize=0x03, mute=1 Amp-In vals: [0x50 0x50] [0x80 0x80] [0x80 0x80] [0x80 0x80] Converter: stream=4, channel=0 SDI-Select: 0 PCM: rates [0x160]: 44100 48000 96000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 D3cold EPSS Power: setting=D0, actual=D0 Connection: 4 0x17* 0x18 0x23 0x24
Node 0x24 [Audio Mixer] wcaps 0x20050b: Stereo Amp-In Amp-In caps: ofs=0x4a, nsteps=0x4a, stepsize=0x03, mute=1 Amp-In vals: [0x00 0x00] [0x00 0x00] Power states: D0 D1 D2 D3 D3cold EPSS Power: setting=D0, actual=D0 Connection: 2 0x10 0x11
BTW there seem to be an audio path from DAC to ADC throungh audio mixer 0x24, does this allow you to record the DAC playback directly ? Using hda-analyzer to change the selection of audio input node 0x14 and fix the amps at node 0x24
Sorry I some how deleted your response... so this may not thread well...
Only about 20% of what you said makes much sense to me so you'll have to bear with me...
- I have the following hardware (alsa-info attached).
Simple mixer control 'Input Source',0 Capabilities: cenum Items: 'Mic' 'Internal Mic' 'Mic 1' Item0: 'Internal Mic' Simple mixer control 'Input Source',1 Capabilities: cenum Items: 'Mic' 'Internal Mic' 'Mic 1' Item0: 'Internal Mic' Simple mixer control 'Input Source',2 Capabilities: cenum Items: 'Mic' 'Internal Mic' 'Mic 1' Item0: 'Internal Mic'
using hda-emu
the driver always use selector 0x17 for the three input source controls
6 Input Source:0 ITEM: 0:Mic, 1:Mic 1, 2:Internal Mic, VAL: [Mic]
set 6 2
send: NID=0x14, VERB=0x701(set_connect_sel), PARM=0x0 receive: 0x0 send: NID=0x17, VERB=0x701(set_connect_sel), PARM=0x3 receive: 0x0
set 7 2
send: NID=0x15, VERB=0x701(set_connect_sel), PARM=0x0 receive: 0x0 send: NID=0x17, VERB=0x701(set_connect_sel), PARM=0x3 receive: 0x0
set 8 2
send: NID=0x16, VERB=0x701(set_connect_sel), PARM=0x0 receive: 0x0 send: NID=0x17, VERB=0x701(set_connect_sel), PARM=0x3 receive: 0x0
It is a bug of the driver to create three input source select controls when there are only two audio selectors 0x17 and 0x18 as node 0x23 is not one of the input pins
The topology does not allow three different input sources with two selectors
Ok so the that makes sense but I'm not sure what you want me to do about it.
- The internal microphone requires that the mic boost channel be
something other than 0 to function properly.
You have to find out whether node 0x1a or 0x1b can be used as the headset jack (headphone with Mic using TRRS connector)
So basically I need to plug a microphone into each port and figure out if both of them work as microphone. A couple things.
1) What if both can be a microphone? 2) If only one can be a microphone, I have no idea how to tell you if its 0x1a or 0x1b.. hda-analyzer/alsa low level stuff is completely new to me.
- Changing what pulseaudio expects things to be labelled causes the
problem to go away. (via the attached patch to /usr/share/pulseaudio/paths/analog-input-mic.conf).
From the discussion with David Henningsson (diwic on IRC). It seems
that pulse doesn't expect a Mic Boost channel to be used with internal microphones. As such to fix this particular hardware, the driver would need to make the internal mic boost be labelled "Internal Mic Boost" as opposed to Mic Boost, which is then is used for both external and internal mics.
Node 0x14 [Audio Input] wcaps 0x100d1b: Stereo Amp-In R/L Control: name="Capture Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Capture Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Device: name="CX20588 Analog", type="Audio", device=0 Amp-In caps: ofs=0x4a, nsteps=0x50, stepsize=0x03, mute=1 Amp-In vals: [0x50 0x50] [0x80 0x80] [0x80 0x80] [0x80 0x80] Converter: stream=4, channel=0 SDI-Select: 0 PCM: rates [0x160]: 44100 48000 96000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 D3cold EPSS Power: setting=D0, actual=D0 Connection: 4 0x17* 0x18 0x23 0x24
Node 0x24 [Audio Mixer] wcaps 0x20050b: Stereo Amp-In Amp-In caps: ofs=0x4a, nsteps=0x4a, stepsize=0x03, mute=1 Amp-In vals: [0x00 0x00] [0x00 0x00] Power states: D0 D1 D2 D3 D3cold EPSS Power: setting=D0, actual=D0 Connection: 2 0x10 0x11
BTW there seem to be an audio path from DAC to ADC throungh audio mixer 0x24, does this allow you to record the DAC playback directly ? Using hda-analyzer to change the selection of audio input node 0x14 and fix the amps at node 0x24
I have no idea what DAC to ADC means. If you want me to do something to test I can do that.
One more thing, if getting this properly fixed can be sped up via a ssh login and IRC chat I can give you access to the machine and be on IRC whenever to get it working.
2013-09-13 12:04, Nathanael D. Noblet skrev:
Sorry I some how deleted your response... so this may not thread well...
Only about 20% of what you said makes much sense to me so you'll have to bear with me...
Raymond often comments on everything that looks strange or interesting to him, even if it's irrelevant to the actual problem. Don't worry.
- I have the following hardware (alsa-info attached).
Simple mixer control 'Input Source',0 Capabilities: cenum Items: 'Mic' 'Internal Mic' 'Mic 1' Item0: 'Internal Mic' Simple mixer control 'Input Source',1 Capabilities: cenum Items: 'Mic' 'Internal Mic' 'Mic 1' Item0: 'Internal Mic' Simple mixer control 'Input Source',2 Capabilities: cenum Items: 'Mic' 'Internal Mic' 'Mic 1' Item0: 'Internal Mic'
using hda-emu
the driver always use selector 0x17 for the three input source controls
6 Input Source:0 ITEM: 0:Mic, 1:Mic 1, 2:Internal Mic, VAL: [Mic]
set 6 2
send: NID=0x14, VERB=0x701(set_connect_sel), PARM=0x0 receive: 0x0 send: NID=0x17, VERB=0x701(set_connect_sel), PARM=0x3 receive: 0x0
set 7 2
send: NID=0x15, VERB=0x701(set_connect_sel), PARM=0x0 receive: 0x0 send: NID=0x17, VERB=0x701(set_connect_sel), PARM=0x3 receive: 0x0
set 8 2
send: NID=0x16, VERB=0x701(set_connect_sel), PARM=0x0 receive: 0x0 send: NID=0x17, VERB=0x701(set_connect_sel), PARM=0x3 receive: 0x0
It is a bug of the driver to create three input source select controls when there are only two audio selectors 0x17 and 0x18 as node 0x23 is not one of the input pins
The topology does not allow three different input sources with two selectors
Ok so the that makes sense but I'm not sure what you want me to do about it.
This indeed looks like a driver bug, but let's figure out the hardware first.
- The internal microphone requires that the mic boost channel be
something other than 0 to function properly.
You have to find out whether node 0x1a or 0x1b can be used as the headset jack (headphone with Mic using TRRS connector)
So basically I need to plug a microphone into each port and figure out if both of them work as microphone. A couple things.
- What if both can be a microphone?
- If only one can be a microphone, I have no idea how to tell you if
its 0x1a or 0x1b.. hda-analyzer/alsa low level stuff is completely new to me.
When you plug something in, you can look at the output of "amixer -D hw:<cardname> contents" to see what, if anything switched to "values=on" instead of "values=off".
We would like you to plug a mic into the mic jack and see in what way the output of "amixer -D hw:<cardname> contents" changes. Then we would like you to plug a headset (with both headphone and mic, like most smartphones have), and again see if there's a difference in amixer. You can also try this with a headphone only in the headphone jack, if you like.
- Changing what pulseaudio expects things to be labelled causes the
problem to go away. (via the attached patch to /usr/share/pulseaudio/paths/analog-input-mic.conf).
From the discussion with David Henningsson (diwic on IRC). It seems
that pulse doesn't expect a Mic Boost channel to be used with internal microphones. As such to fix this particular hardware, the driver would need to make the internal mic boost be labelled "Internal Mic Boost" as opposed to Mic Boost, which is then is used for both external and internal mics.
Node 0x14 [Audio Input] wcaps 0x100d1b: Stereo Amp-In R/L Control: name="Capture Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Capture Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Device: name="CX20588 Analog", type="Audio", device=0 Amp-In caps: ofs=0x4a, nsteps=0x50, stepsize=0x03, mute=1 Amp-In vals: [0x50 0x50] [0x80 0x80] [0x80 0x80] [0x80 0x80] Converter: stream=4, channel=0 SDI-Select: 0 PCM: rates [0x160]: 44100 48000 96000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 D3cold EPSS Power: setting=D0, actual=D0 Connection: 4 0x17* 0x18 0x23 0x24
Node 0x24 [Audio Mixer] wcaps 0x20050b: Stereo Amp-In Amp-In caps: ofs=0x4a, nsteps=0x4a, stepsize=0x03, mute=1 Amp-In vals: [0x00 0x00] [0x00 0x00] Power states: D0 D1 D2 D3 D3cold EPSS Power: setting=D0, actual=D0 Connection: 2 0x10 0x11
BTW there seem to be an audio path from DAC to ADC throungh audio mixer 0x24, does this allow you to record the DAC playback directly ? Using hda-analyzer to change the selection of audio input node 0x14 and fix the amps at node 0x24
I have no idea what DAC to ADC means. If you want me to do something to test I can do that.
This is completely irrelevant to your problem.
On 09/13/2013 06:34 PM, David Henningsson wrote:
- The internal microphone requires that the mic boost channel be
something other than 0 to function properly.
You have to find out whether node 0x1a or 0x1b can be used as the headset jack (headphone with Mic using TRRS connector)
So basically I need to plug a microphone into each port and figure out if both of them work as microphone. A couple things.
- What if both can be a microphone?
- If only one can be a microphone, I have no idea how to tell you if
its 0x1a or 0x1b.. hda-analyzer/alsa low level stuff is completely new to me.
When you plug something in, you can look at the output of "amixer -D hw:<cardname> contents" to see what, if anything switched to "values=on" instead of "values=off".
We would like you to plug a mic into the mic jack and see in what way the output of "amixer -D hw:<cardname> contents" changes. Then we would like you to plug a headset (with both headphone and mic, like most smartphones have), and again see if there's a difference in amixer. You can also try this with a headphone only in the headphone jack, if you like.
So here's what I did. I didn't have a combo headphone/mic thing handy.
1) nothing.out is the netbook with nothing external plugged in. 2) mic.out is when I plugged in a microphone into the mic jack 3) head.out is when there were headphones plugged into the headphone jack 4) both.out is when something was plugged into both (mic into mic and headphone into headphones...
A quick diff shows that amixer is seeing differences. --- nothing.out 2013-09-16 09:11:54.678168182 -0600 +++ mic.out 2013-09-16 09:11:54.675168245 -0600 @@ -6,7 +6,7 @@ : values=on numid=18,iface=CARD,name='Mic Jack' ; type=BOOLEAN,access=r-------,values=1 - : values=off + : values=on numid=20,iface=CARD,name='Mic Jack',index=1 ; type=BOOLEAN,access=r-------,values=1 : values=off
Given this information... what's the next step?
On 09/16/2013 05:14 PM, Nathanael D. Noblet wrote:
On 09/13/2013 06:34 PM, David Henningsson wrote:
- The internal microphone requires that the mic boost channel be
something other than 0 to function properly.
You have to find out whether node 0x1a or 0x1b can be used as the headset jack (headphone with Mic using TRRS connector)
So basically I need to plug a microphone into each port and figure out if both of them work as microphone. A couple things.
- What if both can be a microphone?
- If only one can be a microphone, I have no idea how to tell you if
its 0x1a or 0x1b.. hda-analyzer/alsa low level stuff is completely new to me.
When you plug something in, you can look at the output of "amixer -D hw:<cardname> contents" to see what, if anything switched to "values=on" instead of "values=off".
We would like you to plug a mic into the mic jack and see in what way the output of "amixer -D hw:<cardname> contents" changes. Then we would like you to plug a headset (with both headphone and mic, like most smartphones have), and again see if there's a difference in amixer. You can also try this with a headphone only in the headphone jack, if you like.
So here's what I did. I didn't have a combo headphone/mic thing handy.
- nothing.out is the netbook with nothing external plugged in.
- mic.out is when I plugged in a microphone into the mic jack
- head.out is when there were headphones plugged into the headphone jack
- both.out is when something was plugged into both (mic into mic and
headphone into headphones...
A quick diff shows that amixer is seeing differences. --- nothing.out 2013-09-16 09:11:54.678168182 -0600 +++ mic.out 2013-09-16 09:11:54.675168245 -0600 @@ -6,7 +6,7 @@ : values=on numid=18,iface=CARD,name='Mic Jack' ; type=BOOLEAN,access=r-------,values=1
- : values=off
- : values=on
numid=20,iface=CARD,name='Mic Jack',index=1 ; type=BOOLEAN,access=r-------,values=1 : values=off
Given this information... what's the next step?
Matching this with your alsa-info, we can see that 'Mic Jack' corresponds to 0x1b and 'Mic Jack', index=1 corresponds to 0x1a.
Hence you could try turning pin 0x1a to "not connected" in hda-jack-retask. (I don't know how/if hda-jack-retask is packaged in Fedora, but it is part of alsa-tools.)
If this resolves your problem, we could then try making that the default in upcoming kernels, but the question is we really dare to do that, without clear confirmation that 0x1a is actually useless. In current state it's a bit buggy, but if the headphone jack is actually a headset jack turning that off would make the headset mic go from "needs manual adjustment to work" to "completely unusuable".
On 09/16/2013 03:57 PM, David Henningsson wrote:
A quick diff shows that amixer is seeing differences. --- nothing.out 2013-09-16 09:11:54.678168182 -0600 +++ mic.out 2013-09-16 09:11:54.675168245 -0600 @@ -6,7 +6,7 @@ : values=on numid=18,iface=CARD,name='Mic Jack' ; type=BOOLEAN,access=r-------,values=1
- : values=off
- : values=on numid=20,iface=CARD,name='Mic Jack',index=1 ; type=BOOLEAN,access=r-------,values=1 : values=off
Given this information... what's the next step?
Matching this with your alsa-info, we can see that 'Mic Jack' corresponds to 0x1b and 'Mic Jack', index=1 corresponds to 0x1a.
Hence you could try turning pin 0x1a to "not connected" in hda-jack-retask. (I don't know how/if hda-jack-retask is packaged in Fedora, but it is part of alsa-tools.)
If this resolves your problem, we could then try making that the default in upcoming kernels, but the question is we really dare to do that, without clear confirmation that 0x1a is actually useless. In current state it's a bit buggy, but if the headphone jack is actually a headset jack turning that off would make the headset mic go from "needs manual adjustment to work" to "completely unusuable".
I located a headset (mic and headphones). Plugged them into the headphone jack. It seems the mic was 'somewhat' active in that if I clicked the mic it would register audio on the vumeter. I did a recording and got some noise from it but it wasn't really clear. I don't know if this means anything. I've attached the nothing.out and a headset.out showing what has changed... Its considerably different than the other simple ones. Thoughts?
--- nothing.out 2013-09-16 09:11:54.678168182 -0600 +++ headset.out 2013-09-18 09:25:37.744247730 -0600 @@ -1,6 +1,6 @@ numid=21,iface=CARD,name='Headphone Jack' ; type=BOOLEAN,access=r-------,values=1 - : values=off + : values=on numid=19,iface=CARD,name='Internal Mic Phantom Jack' ; type=BOOLEAN,access=r-------,values=1 : values=on @@ -9,7 +9,7 @@ : values=off numid=20,iface=CARD,name='Mic Jack',index=1 ; type=BOOLEAN,access=r-------,values=1 - : values=off + : values=on numid=22,iface=CARD,name='Speaker Phantom Jack' ; type=BOOLEAN,access=r-------,values=1 : values=on @@ -73,7 +73,7 @@ ; Item #0 'Mic' ; Item #1 'Internal Mic' ; Item #2 'Mic 1' - : values=0 + : values=1 numid=7,iface=MIXER,name='Input Source',index=1 ; type=ENUMERATED,access=rw------,values=1,items=3 ; Item #0 'Mic' @@ -88,10 +88,10 @@ : values=1 numid=4,iface=MIXER,name='Speaker Playback Switch' ; type=BOOLEAN,access=rw------,values=2 - : values=on,on + : values=off,off numid=3,iface=MIXER,name='Speaker Playback Volume' ; type=INTEGER,access=rw---R--,values=2,min=0,max=74,step=0 - : values=74,74 + : values=0,0 | dBscale-min=-74.00dB,step=1.00dB,mute=0 numid=26,iface=PCM,name='Capture Channel Map' ; type=INTEGER,access=r----R--,values=2,min=0,max=36,step=0
On 09/16/2013 03:57 PM, David Henningsson wrote:
Matching this with your alsa-info, we can see that 'Mic Jack' corresponds to 0x1b and 'Mic Jack', index=1 corresponds to 0x1a.
Hence you could try turning pin 0x1a to "not connected" in hda-jack-retask. (I don't know how/if hda-jack-retask is packaged in Fedora, but it is part of alsa-tools.)
If this resolves your problem, we could then try making that the default in upcoming kernels, but the question is we really dare to do that, without clear confirmation that 0x1a is actually useless. In current state it's a bit buggy, but if the headphone jack is actually a headset jack turning that off would make the headset mic go from "needs manual adjustment to work" to "completely unusuable".
So that adjustment allows the internal microphone to be useable. However the mic in jack is now completely unusable. With a headset or a plain microphone.
Thoughts?
On 10/09/2013 01:46 PM, Nathanael D. Noblet wrote:
On 09/16/2013 03:57 PM, David Henningsson wrote:
Matching this with your alsa-info, we can see that 'Mic Jack' corresponds to 0x1b and 'Mic Jack', index=1 corresponds to 0x1a.
Hence you could try turning pin 0x1a to "not connected" in hda-jack-retask. (I don't know how/if hda-jack-retask is packaged in Fedora, but it is part of alsa-tools.)
If this resolves your problem, we could then try making that the default in upcoming kernels, but the question is we really dare to do that, without clear confirmation that 0x1a is actually useless. In current state it's a bit buggy, but if the headphone jack is actually a headset jack turning that off would make the headset mic go from "needs manual adjustment to work" to "completely unusuable".
So that adjustment allows the internal microphone to be useable. However the mic in jack is now completely unusable. With a headset or a plain microphone.
Thoughts?
Actually I was wrong. I plugged it into the wrong jack. With that retask everything seems to work now. Plugging in a microphone into the mic jack picks up that audio, unplugging it uses the built in mic. So that's good. What's the next step?
On 10/09/2013 09:58 PM, Nathanael D. Noblet wrote:
On 10/09/2013 01:46 PM, Nathanael D. Noblet wrote:
On 09/16/2013 03:57 PM, David Henningsson wrote:
Matching this with your alsa-info, we can see that 'Mic Jack' corresponds to 0x1b and 'Mic Jack', index=1 corresponds to 0x1a.
Hence you could try turning pin 0x1a to "not connected" in hda-jack-retask. (I don't know how/if hda-jack-retask is packaged in Fedora, but it is part of alsa-tools.)
If this resolves your problem, we could then try making that the default in upcoming kernels, but the question is we really dare to do that, without clear confirmation that 0x1a is actually useless. In current state it's a bit buggy, but if the headphone jack is actually a headset jack turning that off would make the headset mic go from "needs manual adjustment to work" to "completely unusuable".
So that adjustment allows the internal microphone to be useable. However the mic in jack is now completely unusable. With a headset or a plain microphone.
Thoughts?
Actually I was wrong. I plugged it into the wrong jack. With that retask everything seems to work now. Plugging in a microphone into the mic jack picks up that audio, unplugging it uses the built in mic. So that's good. What's the next step?
Ok, so I made a patch (just sent it) that properly names the headset mic as such, so we don't end up with "Mic" and "Mic 1" but "Mic" and "Headset Mic" instead.
It is a step in the right direction and I encourage you to test it - but it does not solve the more difficult problem with the parser: that all three inputs go through node 0x17, and that node gets a control "xxx Boost" that's named after one of them, without indication that it actually controls boost for all three of them.
- I have the following hardware (alsa-info attached).
Simple mixer control 'Input Source',0 Capabilities: cenum Items: 'Mic' 'Internal Mic' 'Mic 1' Item0: 'Internal Mic' Simple mixer control 'Input Source',1 Capabilities: cenum Items: 'Mic' 'Internal Mic' 'Mic 1' Item0: 'Internal Mic' Simple mixer control 'Input Source',2 Capabilities: cenum Items: 'Mic' 'Internal Mic' 'Mic 1' Item0: 'Internal Mic'
using hda-emu
the driver always use selector 0x17 for the three input source controls
6 Input Source:0 ITEM: 0:Mic, 1:Mic 1, 2:Internal Mic, VAL: [Mic]
set 6 2
send: NID=0x14, VERB=0x701(set_connect_sel), PARM=0x0 receive: 0x0 send: NID=0x17, VERB=0x701(set_connect_sel), PARM=0x3 receive: 0x0
set 7 2
send: NID=0x15, VERB=0x701(set_connect_sel), PARM=0x0 receive: 0x0 send: NID=0x17, VERB=0x701(set_connect_sel), PARM=0x3 receive: 0x0
set 8 2
send: NID=0x16, VERB=0x701(set_connect_sel), PARM=0x0 receive: 0x0 send: NID=0x17, VERB=0x701(set_connect_sel), PARM=0x3 receive: 0x0
It is a bug of the driver to create three input source select controls when there are only two audio selectors 0x17 and 0x18 as node 0x23 is not one of the input pins
The topology does not allow three different input sources with two selectors
Ok so the that makes sense but I'm not sure what you want me to do about it.
unfortunately even auto mic is enabled by removing one of the external mic, the driver only use 0x17
hda-codec: Enable auto-mic switch on NID 0x1e/0x1b/0x0
jack
NID 0x19: cfg 0x03211040: [Jack] HP Out at Ext Left NID 0x1b: cfg 0x03a19030: [Jack] Mic at Ext Left NID 0x1e: cfg 0x95a70120: [Fixed] Mic at Int Top NID 0x1f: cfg 0x92170110: [Fixed] Speaker at Int Front
jack 0x1b 1
send: NID=0x1b, VERB=0xf09(get_pin_sense), PARM=0x0 receive: 0x80000000 send: NID=0x14, VERB=0x701(set_connect_sel), PARM=0x0 receive: 0x0 send: NID=0x17, VERB=0x701(set_connect_sel), PARM=0x1 receive: 0x0 JACK report Headphone, status 0 CTL Notify: Mic Jack:0, mask=1 JACK report Mic, status 2
jack 0x1b 0
send: NID=0x1b, VERB=0xf09(get_pin_sense), PARM=0x0 receive: 0x0 send: NID=0x14, VERB=0x701(set_connect_sel), PARM=0x0 receive: 0x0 send: NID=0x17, VERB=0x701(set_connect_sel), PARM=0x3 receive: 0x0 JACK report Headphone, status 0 CTL Notify: Mic Jack:0, mask=1 JACK report Mic, status 0
- The internal microphone requires that the mic boost channel be
something other than 0 to function properly.
You have to find out whether node 0x1a or 0x1b can be used as the headset jack (headphone with Mic using TRRS connector)
So basically I need to plug a microphone into each port and figure out if both of them work as microphone. A couple things.
Refer to Aspire One Series Quick Guide, the headphone jack support headphone or speaker, what you need is to find out which node is the mic jack (0x1a or 0x1b) ?
icon Item Description Headphone/speaker/ Connects to audio line-out devices line-out jack (e.g., speakers, headphones). Microphone-in jack Accepts inputs from external microphones.
From the discussion with David Henningsson (diwic on IRC). It seems
that pulse doesn't expect a Mic Boost channel to be used with internal microphones. As such to fix this particular hardware, the driver would need to make the internal mic boost be labelled "Internal Mic Boost" as opposed to Mic Boost, which is then is used for both external and internal mics.
As there is no path for the input pins to the output pins (No Mic playback volume)
The capabilites of this mic boost should be cvolume instead of volume
it should not appear in Playback View of alsamixer
Simple mixer control 'Mic Boost',0 Capabilities: volume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 4 Front Left: 0 [0%] [0.00dB] Front Right: 0 [0%] [0.00dB]
Node 0x14 [Audio Input] wcaps 0x100d1b: Stereo Amp-In R/L Control: name="Capture Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Capture Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Device: name="CX20588 Analog", type="Audio", device=0 Amp-In caps: ofs=0x4a, nsteps=0x50, stepsize=0x03, mute=1 Amp-In vals: [0x50 0x50] [0x80 0x80] [0x80 0x80] [0x80 0x80] Converter: stream=4, channel=0 SDI-Select: 0 PCM: rates [0x160]: 44100 48000 96000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 D3cold EPSS Power: setting=D0, actual=D0 Connection: 4 0x17* 0x18 0x23 0x24
Node 0x24 [Audio Mixer] wcaps 0x20050b: Stereo Amp-In Amp-In caps: ofs=0x4a, nsteps=0x4a, stepsize=0x03, mute=1 Amp-In vals: [0x00 0x00] [0x00 0x00] Power states: D0 D1 D2 D3 D3cold EPSS Power: setting=D0, actual=D0 Connection: 2 0x10 0x11
BTW there seem to be an audio path from DAC to ADC throungh audio mixer 0x24, does this allow you to record the DAC playback directly ? Using hda-analyzer to change the selection of audio input node 0x14 and fix the amps at node 0x24
I have no idea what DAC to ADC means.
[Audio Output] 0x10/0x11 -> [Audio Mixer] 0x24 -> [Audio Selector] 0x17 -> [Audio Input] 0x14
record the playing signal without a loopback cable
Node 0x14 [Audio Input] wcaps 0x100d1b: Stereo Amp-In R/L Control: name="Capture Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Capture Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Device: name="CX20588 Analog", type="Audio", device=0 Amp-In caps: ofs=0x4a, nsteps=0x50, stepsize=0x03, mute=1 Amp-In vals: [0x50 0x50] [0x80 0x80] [0x80 0x80] [0x80 0x80] Converter: stream=4, channel=0 SDI-Select: 0 PCM: rates [0x160]: 44100 48000 96000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 D3cold EPSS Power: setting=D0, actual=D0 Connection: 4 0x17* 0x18 0x23 0x24
Node 0x24 [Audio Mixer] wcaps 0x20050b: Stereo Amp-In Amp-In caps: ofs=0x4a, nsteps=0x4a, stepsize=0x03, mute=1 Amp-In vals: [0x00 0x00] [0x00 0x00] Power states: D0 D1 D2 D3 D3cold EPSS Power: setting=D0, actual=D0 Connection: 2 0x10 0x11
BTW there seem to be an audio path from DAC to ADC throungh audio mixer 0x24, does this allow you to record the DAC playback directly ? Using hda-analyzer to change the selection of audio input node 0x14 and fix the amps at node 0x24
I have no idea what DAC to ADC means. If you want me to do something to test I can do that.
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/plain/Documenta...
hints:: Shows / stores hint strings for codec parsers for any use. Its format is `key = value`. For example, passing `jack_detect = no` will disable the jack detection of the machine completely.
Hint Strings ~~~~~~~~~~~~ The codec parser have several switches and adjustment knobs for matching better with the actual codec or device behavior. Many of them can be adjusted dynamically via "hints" strings as mentioned in the section above. For example, by passing `jack_detect = no` string via sysfs or a patch file, you can disable the jack detection, thus the codec parser will skip the features like auto-mute or mic auto-switch. As a boolean value, either `yes`, `no`, `true`, `false`, `1` or `0` can be passed.
The generic parser supports the following hints:
- add_stereo_mix_input (bool): add the stereo mix (analog-loopback mix) to the input mux if available - mixer_nid (int): specifies the widget NID of the analog-loopback mixer
specify hints
mixer_nid = 0x24 add_stereo_mix_input = true
get 6
6 Input Source:0 ITEM: 0:Mic, 1:Mic 1, 2:Internal Mic, 3:Stereo Mix, VAL: [Mic]
set 6 3
send: NID=0x14, VERB=0x701(set_connect_sel), PARM=0x3 receive: 0x0 send: NID=0x24, VERB=0x360(set_amp_gain_mute,I:L#0), PARM=0x4a receive: 0x0 send: NID=0x24, VERB=0x350(set_amp_gain_mute,I:R#0), PARM=0x4a receive: 0x0
participants (3)
-
David Henningsson -
Nathanael D. Noblet -
Raymond Yau