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.
