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
