Re: [pulseaudio-discuss] [PATCH] alsa: make headset-mic scanned earlier than headphone-mic

[Hui Wang]

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

[Tanu Kaskinen]

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

[Hui Wang]

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

[Tanu Kaskinen]

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

[Hui Wang]

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

[Tanu Kaskinen]

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

[Hui Wang]

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

[Tanu Kaskinen]

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

[Hui Wang]

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

[Hui Wang]

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