[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.