Re: [pulseaudio-discuss] [PATCH] alsa: make headset-mic scanned earlier than headphone-mic
keep the headphone-mic's priority to 87, after booting up, the default input active_port is headset-mic (that is expected), I plug a microphone and select "headphone-mic" from UI program, the input active_port is headphone-mic now, then I unplug the headphone-mic, the input active_port is changed back to headset-mic. So changing priority really can fix these two issues. Do both ports change availability status from "no" to "unknown" when anything is plugged in? That would explain why increasing the headset- mic priority fixes both issues. Yes, it works in the way as you guess. I guess you'll write a patch for increasing the port priority. I would strongly recommend changing the UI program as well, but that's up to you. I will write a patch to increase port priority first, later I will improve the UI program. Thanks, Hui. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] alsa: make headset-mic scanned earlier than headphone-mic
On Wed, 2017-05-24 at 10:28 +0800, Hui Wang wrote: > On 05/23/2017 07:35 PM, Tanu Kaskinen wrote: > > On Tue, 2017-05-23 at 17:36 +0800, Hui Wang wrote: > > > When user plug in a headphone and select the headphone, the UI program > > > will set the headphone to be the active_port of pa_sink, and kernel > > > audio driver (patch_reaktek) will configure the codec to make that audio > > > jack work as a headphone jack > > > > What makes the kernel do that? Does the kernel rely only on the mixer > > settings set by pulseaudio to figure out how to configure the jack? > > Which mixer elements affect the kernel's decision? > > It depends on the mixer "Capture Source". For what it's worth, I think it would make sense for the kernel to provide "none" as an option for the capture source. That would make the semantics clearer. (I don't expect this to be added to the kernel, because it's not strictly necessary, and taking advantage of it in pulseaudio would be complicated too.) > > In the kernel, the function alc_update_headset_mode() in the > $kernel_dir/sound/pci/hda/patch_realtek.c will handle it. > > > > > When user plug in a headset and select the headset-mic, the UI program > > > will set the headphone to be the active_port of pa_sink and set the > > > headset-mic to be the active_port of pa_source, and kernel driver will > > > configure the audio jack to be the headset jack > > > > > > > > > When user plug in a microphone and select the headphone-mic, the UI > > > program will set the headphone-mic to be the active_port of pa_source, > > > and kernel driver will configure the audio jack to be the microphone > > > jack, then this jack can't work with headphone. > > > > > > > However, that still doesn't fix the bug properly, I think. What if the > > > > user plugs in a microphone and selects it in the UI? What will make > > > > pulseaudio switch to the headphone-mic? > > > > > > The UI program will do that. The UI program will call > > > pa_context_set_source_port_by_index() to do that. > > > >What will make pulseaudio > > > > switch to the headset-mic port if headphones or a headset is plugged in > > > > later? > > > > > > This problem does not exist, since there is only one physical jack, if > > > user want to plug headset or headphone, he need to unplug the microphone > > > first. After user plug in the headphone or headset, the UI program will > > > call pa_context_set_source/sink_port_by_index() to set active port > > > according to user's choice. > > > > But isn't it so that if the user selects headphones, the UI program > > won't change the source port? So if the user first had a microphone > > plugged in, and then unplugged that and plugged in headphones instead, > > the headphones won't work, because the headphone-mic port is still > > active. > > > > Yes, you are right, this is another issue I did not think about before. > Because most of the machines (laptop) have internal microphone, and > after the headphone-mic is unplugged, the input source will switch to > internal microphone automatically, so this issue has not exposed. > > I admit that UI program has some problems, it should not only take care > of output devices when users select headphone. The UI program needs to > be improved. > > BTW, I just did a test, increased the headset-mic's priority to 88, and > keep the headphone-mic's priority to 87, after booting up, the default > input active_port is headset-mic (that is expected), I plug a microphone > and select "headphone-mic" from UI program, the input active_port is > headphone-mic now, then I unplug the headphone-mic, the input > active_port is changed back to headset-mic. So changing priority really > can fix these two issues. Do both ports change availability status from "no" to "unknown" when anything is plugged in? That would explain why increasing the headset- mic priority fixes both issues. I guess you'll write a patch for increasing the port priority. I would strongly recommend changing the UI program as well, but that's up to you. -- Tanu https://www.patreon.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] alsa: make headset-mic scanned earlier than headphone-mic
On 05/23/2017 07:35 PM, Tanu Kaskinen wrote: On Tue, 2017-05-23 at 17:36 +0800, Hui Wang wrote: On 05/23/2017 04:20 PM, Tanu Kaskinen wrote: On Tue, 2017-05-23 at 11:04 +0800, Hui Wang wrote: On 05/20/2017 10:51 PM, Tanu Kaskinen wrote: On Fri, 2017-05-19 at 09:29 +0800, Hui Wang wrote: Hello Tanu, Could you please help take a look at this patch? This patch really fix an issue on some Dell machines (with realtek codec and has no internal microphone on them), And I think this minor change will not introduce regression, it is pretty safe. The patch only changes the order in which headset-mic and headphone-mic are listed, and that order should not have any real impact on anything. There's clearly a bug somewhere, but the bug can't be that the paths are listed in the wrong order, since the order should not matter. Yes, you are right. In theory, the headset-mic and headphone-mic have the same priority, so exchanging their order should not have any real impact on anything. But in practice, this bug exposes that in some situation( when there are only headphone-mic and headset-mic, and neither of them is plugged in.), the headphone-mic is not suitable to be the default active_port. So do you think if it is acceptable that I don't exchange their order, I just adjust their priorities to make the headset-mic's priority a bit higher than headphone-mic's? If I understand correctly, headphones and headsets only work with the headset-mic port, and microphones only work with the headphone-mic port. Since it's more likely that a user plugs in headphones or a headset than a microphone, I think it's ok to make the headset-mic priority a bit higher than headphone-mic. There is only one audio jack, users can plug headphone, headset or microphone into it. On some Dell machines which has realtek codec, the codec/audio jack can't distinguish from hardware perspective what devices the user plugged in, so users need to do a choice from UI program: When user plug in a headphone and select the headphone, the UI program will set the headphone to be the active_port of pa_sink, and kernel audio driver (patch_reaktek) will configure the codec to make that audio jack work as a headphone jack What makes the kernel do that? Does the kernel rely only on the mixer settings set by pulseaudio to figure out how to configure the jack? Which mixer elements affect the kernel's decision? It depends on the mixer "Capture Source". In the kernel, the function alc_update_headset_mode() in the $kernel_dir/sound/pci/hda/patch_realtek.c will handle it. When user plug in a headset and select the headset-mic, the UI program will set the headphone to be the active_port of pa_sink and set the headset-mic to be the active_port of pa_source, and kernel driver will configure the audio jack to be the headset jack When user plug in a microphone and select the headphone-mic, the UI program will set the headphone-mic to be the active_port of pa_source, and kernel driver will configure the audio jack to be the microphone jack, then this jack can't work with headphone. However, that still doesn't fix the bug properly, I think. What if the user plugs in a microphone and selects it in the UI? What will make pulseaudio switch to the headphone-mic? The UI program will do that. The UI program will call pa_context_set_source_port_by_index() to do that. What will make pulseaudio switch to the headset-mic port if headphones or a headset is plugged in later? This problem does not exist, since there is only one physical jack, if user want to plug headset or headphone, he need to unplug the microphone first. After user plug in the headphone or headset, the UI program will call pa_context_set_source/sink_port_by_index() to set active port according to user's choice. But isn't it so that if the user selects headphones, the UI program won't change the source port? So if the user first had a microphone plugged in, and then unplugged that and plugged in headphones instead, the headphones won't work, because the headphone-mic port is still active. Yes, you are right, this is another issue I did not think about before. Because most of the machines (laptop) have internal microphone, and after the headphone-mic is unplugged, the input source will switch to internal microphone automatically, so this issue has not exposed. I admit that UI program has some problems, it should not only take care of output devices when users select headphone. The UI program needs to be improved. BTW, I just did a test, increased the headset-mic's priority to 88, and keep the headphone-mic's priority to 87, after booting up, the default input active_port is headset-mic (that is expected), I plug a microphone and select "headphone-mic" from UI program, the input active_port is headphone-mic now, then I unplug the headphone-mic, the input active_port is changed back to headset-mic. So changing priority really can fix these two issues.
Re: [pulseaudio-discuss] [PATCH] alsa: make headset-mic scanned earlier than headphone-mic
On Tue, 2017-05-23 at 17:36 +0800, Hui Wang wrote: > On 05/23/2017 04:20 PM, Tanu Kaskinen wrote: > > On Tue, 2017-05-23 at 11:04 +0800, Hui Wang wrote: > > > On 05/20/2017 10:51 PM, Tanu Kaskinen wrote: > > > > On Fri, 2017-05-19 at 09:29 +0800, Hui Wang wrote: > > > > > Hello Tanu, > > > > > > > > > > Could you please help take a look at this patch? This patch really fix > > > > > an issue on some Dell machines (with realtek codec and has no internal > > > > > microphone on them), And I think this minor change will not introduce > > > > > regression, it is pretty safe. > > > > > > > > The patch only changes the order in which headset-mic and headphone-mic > > > > are listed, and that order should not have any real impact on anything. > > > > There's clearly a bug somewhere, but the bug can't be that the paths > > > > are listed in the wrong order, since the order should not matter. > > > > > > Yes, you are right. In theory, the headset-mic and headphone-mic have > > > the same priority, so exchanging their order should not have any real > > > impact on anything. > > > > > > But in practice, this bug exposes that in some situation( when there are > > > only headphone-mic and headset-mic, and neither of them is plugged in.), > > > the headphone-mic is not suitable to be the default active_port. So do > > > you think if it is acceptable that I don't exchange their order, I just > > > adjust their priorities to make the headset-mic's priority a bit higher > > > than headphone-mic's? > > > > If I understand correctly, headphones and headsets only work with the > > headset-mic port, and microphones only work with the headphone-mic > > port. Since it's more likely that a user plugs in headphones or a > > headset than a microphone, I think it's ok to make the headset-mic > > priority a bit higher than headphone-mic. > > There is only one audio jack, users can plug headphone, headset or > microphone into it. On some Dell machines which has realtek codec, the > codec/audio jack can't distinguish from hardware perspective what > devices the user plugged in, so users need to do a choice from UI program: > > When user plug in a headphone and select the headphone, the UI program > will set the headphone to be the active_port of pa_sink, and kernel > audio driver (patch_reaktek) will configure the codec to make that audio > jack work as a headphone jack What makes the kernel do that? Does the kernel rely only on the mixer settings set by pulseaudio to figure out how to configure the jack? Which mixer elements affect the kernel's decision? > When user plug in a headset and select the headset-mic, the UI program > will set the headphone to be the active_port of pa_sink and set the > headset-mic to be the active_port of pa_source, and kernel driver will > configure the audio jack to be the headset jack > > > When user plug in a microphone and select the headphone-mic, the UI > program will set the headphone-mic to be the active_port of pa_source, > and kernel driver will configure the audio jack to be the microphone > jack, then this jack can't work with headphone. > > > > > However, that still doesn't fix the bug properly, I think. What if the > > user plugs in a microphone and selects it in the UI? What will make > > pulseaudio switch to the headphone-mic? > > The UI program will do that. The UI program will call > pa_context_set_source_port_by_index() to do that. > > What will make pulseaudio > > switch to the headset-mic port if headphones or a headset is plugged in > > later? > > This problem does not exist, since there is only one physical jack, if > user want to plug headset or headphone, he need to unplug the microphone > first. After user plug in the headphone or headset, the UI program will > call pa_context_set_source/sink_port_by_index() to set active port > according to user's choice. But isn't it so that if the user selects headphones, the UI program won't change the source port? So if the user first had a microphone plugged in, and then unplugged that and plugged in headphones instead, the headphones won't work, because the headphone-mic port is still active. -- Tanu https://www.patreon.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] alsa: make headset-mic scanned earlier than headphone-mic
On 05/23/2017 04:20 PM, Tanu Kaskinen wrote: On Tue, 2017-05-23 at 11:04 +0800, Hui Wang wrote: On 05/20/2017 10:51 PM, Tanu Kaskinen wrote: On Fri, 2017-05-19 at 09:29 +0800, Hui Wang wrote: Hello Tanu, Could you please help take a look at this patch? This patch really fix an issue on some Dell machines (with realtek codec and has no internal microphone on them), And I think this minor change will not introduce regression, it is pretty safe. The patch only changes the order in which headset-mic and headphone-mic are listed, and that order should not have any real impact on anything. There's clearly a bug somewhere, but the bug can't be that the paths are listed in the wrong order, since the order should not matter. Yes, you are right. In theory, the headset-mic and headphone-mic have the same priority, so exchanging their order should not have any real impact on anything. But in practice, this bug exposes that in some situation( when there are only headphone-mic and headset-mic, and neither of them is plugged in.), the headphone-mic is not suitable to be the default active_port. So do you think if it is acceptable that I don't exchange their order, I just adjust their priorities to make the headset-mic's priority a bit higher than headphone-mic's? If I understand correctly, headphones and headsets only work with the headset-mic port, and microphones only work with the headphone-mic port. Since it's more likely that a user plugs in headphones or a headset than a microphone, I think it's ok to make the headset-mic priority a bit higher than headphone-mic. There is only one audio jack, users can plug headphone, headset or microphone into it. On some Dell machines which has realtek codec, the codec/audio jack can't distinguish from hardware perspective what devices the user plugged in, so users need to do a choice from UI program: When user plug in a headphone and select the headphone, the UI program will set the headphone to be the active_port of pa_sink, and kernel audio driver (patch_reaktek) will configure the codec to make that audio jack work as a headphone jack When user plug in a headset and select the headset-mic, the UI program will set the headphone to be the active_port of pa_sink and set the headset-mic to be the active_port of pa_source, and kernel driver will configure the audio jack to be the headset jack When user plug in a microphone and select the headphone-mic, the UI program will set the headphone-mic to be the active_port of pa_source, and kernel driver will configure the audio jack to be the microphone jack, then this jack can't work with headphone. However, that still doesn't fix the bug properly, I think. What if the user plugs in a microphone and selects it in the UI? What will make pulseaudio switch to the headphone-mic? The UI program will do that. The UI program will call pa_context_set_source_port_by_index() to do that. What will make pulseaudio switch to the headset-mic port if headphones or a headset is plugged in later? This problem does not exist, since there is only one physical jack, if user want to plug headset or headphone, he need to unplug the microphone first. After user plug in the headphone or headset, the UI program will call pa_context_set_source/sink_port_by_index() to set active port according to user's choice. It sounds like the kernel might be buggy too. Why does it have to disable headphone output if pulseaudio's active source port happens to be headphone-mic? It is not a bug, some realtek codec can configure a port (pins) to be input or output, that means a physical jack can be configured as headphone jack or microphone jack. When headphone-mic is active source port, the audio driver only disable the headphone shared the same port with this headphone-mic, the kernel driver doesn't disable other headphones. The kernel seems to select from two mic modes: headset or microphone, but I don't understand why it doesn't have a mode for no mic input at all, which could be used when headphones are plugged in. For most cases (almost 99.999% cases), the output choice and input choice doesn't impact each other. This problem only happens on some dell machines, which has realtek codec, and has a physical audio jack to support headphone, headset or microphone, and the codec has no hardware ability to distinguish devices. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] alsa: make headset-mic scanned earlier than headphone-mic
On Tue, 2017-05-23 at 11:04 +0800, Hui Wang wrote: > On 05/20/2017 10:51 PM, Tanu Kaskinen wrote: > > On Fri, 2017-05-19 at 09:29 +0800, Hui Wang wrote: > > > Hello Tanu, > > > > > > Could you please help take a look at this patch? This patch really fix > > > an issue on some Dell machines (with realtek codec and has no internal > > > microphone on them), And I think this minor change will not introduce > > > regression, it is pretty safe. > > > > The patch only changes the order in which headset-mic and headphone-mic > > are listed, and that order should not have any real impact on anything. > > There's clearly a bug somewhere, but the bug can't be that the paths > > are listed in the wrong order, since the order should not matter. > > Yes, you are right. In theory, the headset-mic and headphone-mic have > the same priority, so exchanging their order should not have any real > impact on anything. > > But in practice, this bug exposes that in some situation( when there are > only headphone-mic and headset-mic, and neither of them is plugged in.), > the headphone-mic is not suitable to be the default active_port. So do > you think if it is acceptable that I don't exchange their order, I just > adjust their priorities to make the headset-mic's priority a bit higher > than headphone-mic's? If I understand correctly, headphones and headsets only work with the headset-mic port, and microphones only work with the headphone-mic port. Since it's more likely that a user plugs in headphones or a headset than a microphone, I think it's ok to make the headset-mic priority a bit higher than headphone-mic. However, that still doesn't fix the bug properly, I think. What if the user plugs in a microphone and selects it in the UI? What will make pulseaudio switch to the headphone-mic? What will make pulseaudio switch to the headset-mic port if headphones or a headset is plugged in later? It sounds like the kernel might be buggy too. Why does it have to disable headphone output if pulseaudio's active source port happens to be headphone-mic? The kernel seems to select from two mic modes: headset or microphone, but I don't understand why it doesn't have a mode for no mic input at all, which could be used when headphones are plugged in. -- Tanu https://www.patreon.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] alsa: make headset-mic scanned earlier than headphone-mic
On 05/20/2017 10:51 PM, Tanu Kaskinen wrote: On Fri, 2017-05-19 at 09:29 +0800, Hui Wang wrote: Hello Tanu, Could you please help take a look at this patch? This patch really fix an issue on some Dell machines (with realtek codec and has no internal microphone on them), And I think this minor change will not introduce regression, it is pretty safe. The patch only changes the order in which headset-mic and headphone-mic are listed, and that order should not have any real impact on anything. There's clearly a bug somewhere, but the bug can't be that the paths are listed in the wrong order, since the order should not matter. Yes, you are right. In theory, the headset-mic and headphone-mic have the same priority, so exchanging their order should not have any real impact on anything. But in practice, this bug exposes that in some situation( when there are only headphone-mic and headset-mic, and neither of them is plugged in.), the headphone-mic is not suitable to be the default active_port. So do you think if it is acceptable that I don't exchange their order, I just adjust their priorities to make the headset-mic's priority a bit higher than headphone-mic's? If the port must not be headphone-mic when the user chooses headphones in the UI, couldn't the UI program tell pulseaudio to switch to headset-mic? Yes, the UI program could do that. If it is not allowed to adjust their priorities, we have to change the UI program. Thanks, Hui. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] alsa: make headset-mic scanned earlier than headphone-mic
On Fri, 2017-05-19 at 09:29 +0800, Hui Wang wrote: > Hello Tanu, > > Could you please help take a look at this patch? This patch really fix > an issue on some Dell machines (with realtek codec and has no internal > microphone on them), And I think this minor change will not introduce > regression, it is pretty safe. The patch only changes the order in which headset-mic and headphone-mic are listed, and that order should not have any real impact on anything. There's clearly a bug somewhere, but the bug can't be that the paths are listed in the wrong order, since the order should not matter. If the port must not be headphone-mic when the user chooses headphones in the UI, couldn't the UI program tell pulseaudio to switch to headset-mic? -- Tanu https://www.patreon.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] alsa: make headset-mic scanned earlier than headphone-mic
Hello Tanu, Could you please help take a look at this patch? This patch really fix an issue on some Dell machines (with realtek codec and has no internal microphone on them), And I think this minor change will not introduce regression, it is pretty safe. Thanks in advance. Hui. On 05/16/2017 11:21 AM, Hui Wang wrote: On some Dell machines with realtek codec, they have a headset audio jack which supports headphone, headset and pure microphone, but this audio jack can only detect something is plugged in but doesn't have capabilites to distinguish what is plugged in. So we need to apply the fixup similar to ALC298_FIXUP_DELL1_MIC_NO_PRESENCE to the kernel driver. When something is plugged in, a pop-up dialogue shows up and users can select what is plugged in. On some Dell machines (especially desktop computers), they have no internal microphone, if users plug a headphone and select the headphone, the headphone is supposed to work, but there is no sound can be played via headphone. Through debugging, I found the root cause has something to do with the active_port of pa-source, since there is no internal microphone, and there is no other available input devices, the headphone-mic and headset-mic will be the candidates to be the active_port, and they have the same priority and headphone-mic is scanned earlier than headset-mic, so the headphone-mic is set to be the active_port. After users select the headphone, the function alc_update_headset_mode() in the kernel driver will be called, in this function it will check what is the default input device for that jack, if it is headphone-mic, that means users want this jack to work as a pure microphone jack, then it will configure the codec and the jack is changed to be a mic-in jack. As a result even users plug and select the headphone, but this jack can't work with headphone. A simple fix for this issue is to exchange the position of headphone-mic and headset-mic, then the headset-mic will be the active_port of pa-source if there is no internal microphone and no other available input devices. Signed-off-by: Hui Wang --- src/modules/alsa/mixer/profile-sets/default.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/modules/alsa/mixer/profile-sets/default.conf b/src/modules/alsa/mixer/profile-sets/default.conf index f412058..16ee567 100644 --- a/src/modules/alsa/mixer/profile-sets/default.conf +++ b/src/modules/alsa/mixer/profile-sets/default.conf @@ -112,7 +112,7 @@ priority = 2 device-strings = front:%f channel-map = left,right paths-output = analog-output analog-output-lineout analog-output-speaker analog-output-headphones analog-output-headphones-2 -paths-input = analog-input-front-mic analog-input-rear-mic analog-input-internal-mic analog-input-dock-mic analog-input analog-input-mic analog-input-linein analog-input-aux analog-input-video analog-input-tvtuner analog-input-fm analog-input-mic-line analog-input-headphone-mic analog-input-headset-mic +paths-input = analog-input-front-mic analog-input-rear-mic analog-input-internal-mic analog-input-dock-mic analog-input analog-input-mic analog-input-linein analog-input-aux analog-input-video analog-input-tvtuner analog-input-fm analog-input-mic-line analog-input-headset-mic analog-input-headphone-mic priority = 10 [Mapping analog-surround-21] ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] alsa: make headset-mic scanned earlier than headphone-mic
On some Dell machines with realtek codec, they have a headset audio jack which supports headphone, headset and pure microphone, but this audio jack can only detect something is plugged in but doesn't have capabilites to distinguish what is plugged in. So we need to apply the fixup similar to ALC298_FIXUP_DELL1_MIC_NO_PRESENCE to the kernel driver. When something is plugged in, a pop-up dialogue shows up and users can select what is plugged in. On some Dell machines (especially desktop computers), they have no internal microphone, if users plug a headphone and select the headphone, the headphone is supposed to work, but there is no sound can be played via headphone. Through debugging, I found the root cause has something to do with the active_port of pa-source, since there is no internal microphone, and there is no other available input devices, the headphone-mic and headset-mic will be the candidates to be the active_port, and they have the same priority and headphone-mic is scanned earlier than headset-mic, so the headphone-mic is set to be the active_port. After users select the headphone, the function alc_update_headset_mode() in the kernel driver will be called, in this function it will check what is the default input device for that jack, if it is headphone-mic, that means users want this jack to work as a pure microphone jack, then it will configure the codec and the jack is changed to be a mic-in jack. As a result even users plug and select the headphone, but this jack can't work with headphone. A simple fix for this issue is to exchange the position of headphone-mic and headset-mic, then the headset-mic will be the active_port of pa-source if there is no internal microphone and no other available input devices. Signed-off-by: Hui Wang --- src/modules/alsa/mixer/profile-sets/default.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/modules/alsa/mixer/profile-sets/default.conf b/src/modules/alsa/mixer/profile-sets/default.conf index f412058..16ee567 100644 --- a/src/modules/alsa/mixer/profile-sets/default.conf +++ b/src/modules/alsa/mixer/profile-sets/default.conf @@ -112,7 +112,7 @@ priority = 2 device-strings = front:%f channel-map = left,right paths-output = analog-output analog-output-lineout analog-output-speaker analog-output-headphones analog-output-headphones-2 -paths-input = analog-input-front-mic analog-input-rear-mic analog-input-internal-mic analog-input-dock-mic analog-input analog-input-mic analog-input-linein analog-input-aux analog-input-video analog-input-tvtuner analog-input-fm analog-input-mic-line analog-input-headphone-mic analog-input-headset-mic +paths-input = analog-input-front-mic analog-input-rear-mic analog-input-internal-mic analog-input-dock-mic analog-input analog-input-mic analog-input-linein analog-input-aux analog-input-video analog-input-tvtuner analog-input-fm analog-input-mic-line analog-input-headset-mic analog-input-headphone-mic priority = 10 [Mapping analog-surround-21] -- 1.9.1 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss