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.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
