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