Re: [pulseaudio-discuss] [PATCH] alsa: make headset-mic scanned earlier than headphone-mic
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] [PATCH RFC] alsa-mixer: add query_hw_device option to mappings
We have so far assumed that HDMI always uses device indexes 3, 7, 8, 9,
10, 11, 12 and 13. These values are hardcoded in the HDMI path
configuration files (the index is used for setting the ELD device and
the jack mixer element name). The Intel HDMI LPE driver, however, uses
different device numbering scheme.
This patch adds a new configuration option for mappings. The option
tells pulseaudio to query the hw device index using snd_pcm_info(). It's
disabled by default, because querying the hw device doesn't always work
(but it's expected work for all hdmi devices).
This patch doesn't yet use the queried device index, that's left for
subsequent patches.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=100488
---
This is just an RFC at this point. Does the approach seem ok? One issue
with this patch is that if skip-probe is used in some custom profile-set
configuration, then the query is never done, because it happens during
probing. I think that's not a serious problem, because custom
configuration for well-known hardware that doesn't need probing should
be able to continue using hardcoded values.
Here's how the path configuration for HDMI looks currently:
[General]
description = HDMI / DisplayPort 8
priority = 52
eld-device = 13
[Properties]
device.icon_name = video-display
[Jack HDMI/DP,pcm=13]
required = ignore
Regarding the ELD device, my current plan is to allow setting the
"eld-device" option value to "auto", which will use the queried device
index of the mapping.
For the jack element name, I suggest this:
[Jack HDMI/DP]
append-pcm-to-name = yes
As can be expected, that option will append ",pcm=X" to the jack name,
with X replaced by the device index.
Any comments would be welcome.
src/modules/alsa/alsa-mixer.c| 86 +---
src/modules/alsa/alsa-mixer.h| 12
src/modules/alsa/mixer/profile-sets/default.conf | 37 ++
3 files changed, 127 insertions(+), 8 deletions(-)
diff --git a/src/modules/alsa/alsa-mixer.c b/src/modules/alsa/alsa-mixer.c
index f59cad394..6bf8f27fe 100644
--- a/src/modules/alsa/alsa-mixer.c
+++ b/src/modules/alsa/alsa-mixer.c
@@ -3504,6 +3504,7 @@ pa_alsa_mapping *pa_alsa_mapping_get(pa_alsa_profile_set
*ps, const char *name)
pa_sample_spec_init(&m->sample_spec);
pa_channel_map_init(&m->channel_map);
m->proplist = pa_proplist_new();
+m->hw_device_index = -1;
pa_hashmap_put(ps->mappings, m->name, m);
@@ -3641,6 +3642,31 @@ static int
mapping_parse_exact_channels(pa_config_parser_state *state) {
return 0;
}
+static int mapping_parse_query_hw_device(pa_config_parser_state *state) {
+pa_alsa_profile_set *ps;
+pa_alsa_mapping *m;
+int b;
+
+pa_assert(state);
+
+ps = state->userdata;
+
+if (!(m = pa_alsa_mapping_get(ps, state->section))) {
+pa_log("[%s:%u] Option '%s' not expected in section '%s'",
+ state->filename, state->lineno, state->lvalue, state->section);
+return -1;
+}
+
+if ((b = pa_parse_boolean(state->rvalue)) < 0) {
+pa_log("[%s:%u] %s has invalid value '%s'", state->filename,
state->lineno, state->lvalue, state->section);
+return -1;
+}
+
+m->query_hw_device = b;
+
+return 0;
+}
+
static int mapping_parse_element(pa_config_parser_state *state) {
pa_alsa_profile_set *ps;
pa_alsa_mapping *m;
@@ -4052,6 +4078,8 @@ static int mapping_verify(pa_alsa_mapping *m, const
pa_channel_map *bonus) {
m->priority += 30;
}
+pa_log_debug("XXX: Mapping %s: query_hw_device = %s", m->name,
m->query_hw_device ? "true" : "false");
+
return 0;
}
@@ -4357,6 +4385,7 @@ pa_alsa_profile_set* pa_alsa_profile_set_new(const char
*fname, const pa_channel
{ "element-output", mapping_parse_element,NULL, NULL },
{ "direction", mapping_parse_direction, NULL, NULL },
{ "exact-channels", mapping_parse_exact_channels, NULL, NULL },
+{ "query-hw-device",mapping_parse_query_hw_device,NULL, NULL },
/* Shared by [Mapping ...] and [Profile ...] */
{ "description",mapping_parse_description,NULL, NULL },
@@ -4531,6 +4560,25 @@ static int add_profiles_to_probe(
return i;
}
+static int mapping_query_hw_device(pa_alsa_mapping *mapping, snd_pcm_t *pcm) {
+int r;
+snd_pcm_info_t* pcm_info;
+snd_pcm_info_alloca(&pcm_info);
+
+pa_assert(mapping->query_hw_device);
+
+r = snd_pcm_info(pcm, pcm_info);
+if (r < 0) {
+pa_log("Mapping %s has query_hw_device enabled, but snd_pcm_info()
failed %s: ", mapping->name, pa_alsa_strerror(r));
+return -1;
+}
+
+mapping->hw_device_index = snd_pcm_info_get_device(pcm_info);
+pa_log_debug("XXX: Mapping %s: hw_device_index = %u", mapping->name,
(unsigned) mapping->hw_device_index);
+
+return 0;
+}
+
void pa_alsa_profile_set_probe(
pa_alsa_prof
Re: [pulseaudio-discuss] [PATCH] alsa: make headset-mic scanned earlier than headphone-mic
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? > 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. -- Tanu https://www.patreon.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] alsa: make headset-mic scanned earlier than headphone-mic
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. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Service fails on systemctl start. Status always "activating"
On Mon, 2017-05-22 at 15:12 -0700, Karl Stahl wrote: > Ah! Sure enough, I had this line in my pulseaudio.service file: > > Requires=pulseaudio.socket > > I copied this file directly from the Debian source: > https://sources.debian.net/src/pulseaudio/8.0-2/src/daemon/systemd/user/pulseaudio.service.in/ > > Debian trunk must be using a newer version of Pulseaudio than > Raspbian. It looks like the latest version of Pulseaudio is 10.0. > Do you know why Raspbian is still using 5.0? The Raspbian images provided by the Raspberry Pi Foundation are based on the latest Debian stable release, and those stable releases don't happen often. The current Debian stable release still uses pulseaudio 5.0. > This is very interesting! I didn't know that: > "Raspbian disables autospawning at every boot by overwriting > ~/.config/pulse/client.conf" > I actually had tried setting "autospawn=yes" in > /etc/pulse/client.conf (isn't this the master version of > client.conf?), but that seems to have no effect. If ~/.config/pulse/client.conf exists, /etc/pulse/client.conf won't be used at all. > I also don't know how to disable the overwriting of > ~/.config/pulse/client.conf. I don't know that either. I'd like to disable it on my rpi too. > So, now pulseaudio starts at boot, which is fantastic, thank you! > > Alas, I am still having a problem. > Here's my .service file to start my script. > > # > # foo.service > > [Unit] > Description=Foo > Requires=pulseaudio.service > After=network.target pulseaudio.service > > [Service] > Type=simple > ExecStart=/home/pi/foo > Restart=on-failure > > [Install] > WantedBy=default.target > # > > If I start it from the command line, it works just fine, but if I > enable it to run at boot, it doesn't work, and in the logs I see > this: > > ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: > Connection refused > > Any ideas? Maybe a timing issue with the ALSA plugin to interface with > Pulseaudio? No, the alsa plugin is a library that the application loads, not a thing that needs to be started. It could be that pulseaudio is not yet fully ready when your script is started. This is why Type=notify is useful. Try sleeping in the beginning of your script. -- Tanu https://www.patreon.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] alsa: make headset-mic scanned earlier than headphone-mic
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. 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? What will make pulseaudio switch to the headset-mic port if headphones or a headset is plugged in later? 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? 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. -- Tanu https://www.patreon.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
