- Alsa-devel - mailman.alsa-project.org

Setting volume of headphones seems to apply to Speakers as well
by GitHub issues - edited 05 May '21

05 May '21

alsa-project/alsa-utils issue #87 was edited from roboknight: When using amixer in the following way: amixer -c 1 set Headphone 0% mute I receive the following partial output from scontents: Simple mixer control 'Headphone',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 87 Mono: Front Left: Playback 0 [0%] [-65.25dB] [off] Front Right: Playback 0 [0%] [-65.25dB] [off] Simple mixer control 'Speaker',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 87 Mono: Front Left: Playback 87 [100%] [0.00dB] [on] Front Right: Playback 87 [100%] [0.00dB] [on] which looks good. However, it appears that the volume is applied across both the Headphone control and Speaker control (or maybe even just the Master volume) as there is no output from the speakers after this even though it would appear they should have full volume and are not muted. I am using the Ubuntu Groovy Gorilla update, so Linux kernel 5.11. The default installation uses pulseaudio, but I've switched things to pipewire and both cause the same issue presumably because both use ALSA. I started here because amixer seems to at least allow me to identify the problem. When I change the Volume for the Headphones to 100% using the following: amixer -c 1 set Headphone 100% mute the audio from the speakers is then fine. amixer appears to be showing the correct information (as per above) according to the audio, but the Headphone volume seems to be applying to the Speakers as well. Maybe someone can point me in a direction that I can find a solution to this, as it would appear that anytime headphones are plugged in, removing the headphones causes the same situation: no sound. I suspect amixer is working fine, but wherever the volume from amixer is applied, it does not appear to be set appropriately. Issue URL : https://github.com/alsa-project/alsa-utils/issues/87 Repository URL: https://github.com/alsa-project/alsa-utils

1 0

Setting volume of headphones seems to apply to Speakers as well
by GitHub issues - opened 05 May '21

05 May '21

alsa-project/alsa-utils issue #87 was opened from roboknight: When using amixer in the following way: amixer -c 1 set Headphone 0% mute I receive the following partial output from scontents: Simple mixer control 'Headphone',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 87 Mono: Front Left: Playback 0 [0%] [-65.25dB] [off] Front Right: Playback 0 [0%] [-65.25dB] [off] Simple mixer control 'Speaker',0 Capabilities: pvolume pswitch Playback channels: Front Left - Front Right Limits: Playback 0 - 87 Mono: Front Left: Playback 87 [100%] [0.00dB] [on] Front Right: Playback 87 [100%] [0.00dB] [on] which looks good. However, it appears that the volume is applied across both the Headphone control and Speaker control (or maybe even just the Master volume) as there is no output from the speakers after this even though it would appear they should have full volume and are not muted. I am using the Ubuntu Groovy Gorilla update, so Linux kernel 5.11. The default installation uses pulseaudio, but I've switched things to pipewire and both cause the same issue presumable because both use ALSA. I started here because amixer seems to at least allow me to identify the problem. When I change the Volume for the Headphones to 100% using the following: amixer -c 1 set Headphone 100% mute the audio from the speakers is then fine. amixer appears to be showing the correct information (as per above) according to the audio, but the Headphone volume seems to be applying to the Speakers as well. Maybe someone can point me in a direction that I can find a solution to this, as it would appear that anytime headphones are plugged in, removing the headphones causes the same situation: no sound. I suspect amixer is working fine, but wherever the volume from amixer is applied, it does not appear to be set appropriately. Issue URL : https://github.com/alsa-project/alsa-utils/issues/87 Repository URL: https://github.com/alsa-project/alsa-utils

1 0

[a52] Strange behavior with 5.1 surround on ALC1220
by GitHub issues - edited 05 May '21

05 May '21

alsa-project/alsa-plugins issue #21 was edited from davidebeatrici: I originally encountered the issue ~1 year ago, when I started using a motherboard with an ALC1220 on it. The out-of-box experience was flawless: I simply connected the optical SPDIF cable to my amplifier/receiver and stereo sound immediately worked. Once I switched to 5.1 surround, audio output became extremely fast; even videos were affected by it, to the point that they were being reproduced in seconds instead of minutes. After a few days of research and experiments I managed to workaround the issue by replacing the content of `60-a52-encoder.conf` with: ``` pcm.a52 { @args [CARD] @args.CARD { type string } type rate slave { pcm { type a52 card $CARD } rate 48000 } } pcm.pulse { type pulse } ctl.pulse { type pulse } pcm.!default { type pulse } ctl.!default { type pulse } ``` Based on https://help.ubuntu.com/community/DigitalAC-3Pulseaudio#Configuring_asound.…. After that, I wanted to investigate the cause and report my findings to either ALSA or PulseAudio (depending on the results). Unfortunately that never happened and I kinda forgot about it, as [libasound2-plugins](https://packages.debian.org/bullseye/libasound2-plugins) was updated a single time in the past year and thus I only had to replace the file's content once more. Fast-forward to today: I switch from PulseAudio to PipeWire and while troubleshooting https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1143 I decided to try to restore the original file. Interestingly, the behavior is different compared to PulseAudio: audio, instead of being fast, is crackling. It's basically as if a frame every two is being skipped. Unfortunately PipeWire reports no errors whatsoever. Issue URL : https://github.com/alsa-project/alsa-plugins/issues/21 Repository URL: https://github.com/alsa-project/alsa-plugins

1 0

[a52] Strange behavior with 5.1 surround on ALC1220
by GitHub issues - edited 05 May '21

05 May '21

alsa-project/alsa-plugins issue #21 was edited from davidebeatrici: I originally encountered the issue ~1 year ago, when I started using a motherboard with an ALC1120 on it. The out-of-box experience was flawless: I simply connected the optical SPDIF cable to my amplifier/receiver and stereo sound immediately worked. Once I switched to 5.1 surround, audio output became extremely fast; even videos were affected by it, to the point that they were being reproduced in seconds instead of minutes. After a few days of research and experiments I managed to workaround the issue by replacing the content of `60-a52-encoder.conf` with: ``` pcm.a52 { @args [CARD] @args.CARD { type string } type rate slave { pcm { type a52 card $CARD } rate 48000 } } pcm.pulse { type pulse } ctl.pulse { type pulse } pcm.!default { type pulse } ctl.!default { type pulse } ``` Based on https://help.ubuntu.com/community/DigitalAC-3Pulseaudio#Configuring_asound.…. After that, I wanted to investigate the cause and report my findings to either ALSA or PulseAudio (depending on the results). Unfortunately that never happened and I kinda forgot about it, as [libasound2-plugins](https://packages.debian.org/bullseye/libasound2-plugins) was updated a single time in the past year and thus I only had to replace the file's content once more. Fast-forward to today: I switch from PulseAudio to PipeWire and while troubleshooting https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1143 I decided to try to restore the original file. Interestingly, the behavior is different compared to PulseAudio: audio, instead of being fast, is crackling. It's basically as if a frame every two is being skipped. Unfortunately PipeWire reports no errors whatsoever. Issue URL : https://github.com/alsa-project/alsa-plugins/issues/21 Repository URL: https://github.com/alsa-project/alsa-plugins

1 0

[a52] Strange behavior with 5.1 surround on ALC1120
by GitHub issues - opened 05 May '21

05 May '21

alsa-project/alsa-plugins issue #21 was opened from davidebeatrici: I originally encountered the issue ~1 year ago, when I started using a motherboard with an ALC1120 on it. The out-of-box experience was flawless: I simply connected the optical SPDIF cable to my amplifier/receiver and stereo sound immediately worked. Once I switched to 5.1 surround, audio output became extremely fast; even videos were affected by it, to the point that they were being reproduced in seconds instead of minutes. After a few days of research and experiments I managed to workaround the issue by replacing the content of `60-a52-encoder.conf` with: ``` pcm.a52 { @args [CARD] @args.CARD { type string } type rate slave { pcm { type a52 card $CARD } rate 48000 } } pcm.pulse { type pulse } ctl.pulse { type pulse } pcm.!default { type pulse } ctl.!default { type pulse } ``` Based on https://help.ubuntu.com/community/DigitalAC-3Pulseaudio#Configuring_asound.…. After that, I wanted to investigate the cause and report my findings to either ALSA or PulseAudio (depending on the results). Unfortunately that never happened and I kinda forgot about it, as [libasound2-plugins](https://packages.debian.org/bullseye/libasound2-plugins) was updated a single time in the past year and thus I only had to replace the file's content once more. Fast-forward to today: I switch from PulseAudio to PipeWire and while troubleshooting https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1143 I decided to try to restore the original file. Interestingly, the behavior is different compared to PulseAudio: audio, instead of being fast, is crackling. It's basically as if a frame every two is being skipped. Unfortunately PipeWire reports no errors whatsoever. Issue URL : https://github.com/alsa-project/alsa-plugins/issues/21 Repository URL: https://github.com/alsa-project/alsa-plugins

1 0

[PATCH 0/9] ASoC: Intel: add new TGL/ADL configurations
by Pierre-Louis Bossart 04 May '21

04 May '21

Very little code but quite a few descriptors to add TigerLake (TGL) /AlderLake (ADL) ACPI match tables for I2S and SoundWire devices, new dailinks for Bluetooth offload. Some day this will be read from platform firmware. Also clarify how microphones are handled for SoundWire devices, and create modules to avoid linking the same code multiple times. Pierre-Louis Bossart (5): ASoC: Intel: soc-acpi: add ADL SoundWire base configurations ASoC: Intel: soc-acpi: add ADL jack-less SoundWire configurations ASoC: Intel: sof_sdw: add mutual exclusion between PCH DMIC and RT715 ASoC: Intel: boards: handle hda-dsp-common as a module ASoC: Intel: boards: create sof-maxim-common module Vamshi Krishna Gopal (3): ASoC: Intel: soc-acpi: add entries for i2s machines in ADL match table ASoC: Intel: sof_sdw: add quirk for new ADL-P Rvp ASoC: Intel: boards: add support for adl boards in sof-rt5682 Yong Zhi (1): ASoC: Intel: Boards: tgl_max98373: Add BT offload support sound/soc/intel/boards/Kconfig | 18 ++ sound/soc/intel/boards/Makefile | 28 +- sound/soc/intel/boards/bxt_da7219_max98357a.c | 1 + sound/soc/intel/boards/bxt_rt298.c | 1 + sound/soc/intel/boards/cml_rt1011_rt5682.c | 1 + sound/soc/intel/boards/ehl_rt5660.c | 1 + sound/soc/intel/boards/glk_rt5682_max98357a.c | 1 + sound/soc/intel/boards/hda_dsp_common.c | 5 + sound/soc/intel/boards/skl_hda_dsp_generic.c | 1 + sound/soc/intel/boards/sof_da7219_max98373.c | 1 + sound/soc/intel/boards/sof_maxim_common.c | 24 +- sound/soc/intel/boards/sof_maxim_common.h | 6 +- sound/soc/intel/boards/sof_pcm512x.c | 1 + sound/soc/intel/boards/sof_rt5682.c | 67 ++++- sound/soc/intel/boards/sof_sdw.c | 32 ++- sound/soc/intel/boards/sof_sdw_common.h | 1 + sound/soc/intel/boards/sof_sdw_max98373.c | 4 +- .../intel/common/soc-acpi-intel-adl-match.c | 249 ++++++++++++++++++ 18 files changed, 415 insertions(+), 27 deletions(-) -- 2.25.1

2 13

[PATCH alsa-lib] mixer: simple - Fix "Capture Volume" and "Capture Switch" being seen as global controls
by Hans de Goede 04 May '21

04 May '21

Fix the "Capture Volume" and "Capture Switch" exceptions no longer working after commit 86b9c67774bc ("mixer: simple - Unify simple_none: base_len() exception handling") because they were moved to after the suffix checking, so they would be treated as CTL_GLOBAL_VOLUME resp. CTL_GLOBAL_SWITCH based on their suffix before the exception check has a chance to check for a match. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- src/mixer/simple_none.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/src/mixer/simple_none.c b/src/mixer/simple_none.c index 71d88486..9b9f0000 100644 --- a/src/mixer/simple_none.c +++ b/src/mixer/simple_none.c @@ -913,6 +913,16 @@ static int base_len(const char *name, selem_ctl_type_t *type) const struct suf *p; size_t nlen = strlen(name); + /* exception: "Capture Volume" and "Capture Switch" */ + if (!strcmp(name, "Capture Volume")) { + *type = CTL_CAPTURE_VOLUME; + return strlen("Capture"); + } + if (!strcmp(name, "Capture Switch")) { + *type = CTL_CAPTURE_SWITCH; + return strlen("Capture"); + } + for (p = suffixes; p->suffix; p++) { size_t slen = strlen(p->suffix); size_t l; @@ -926,16 +936,6 @@ static int base_len(const char *name, selem_ctl_type_t *type) } } - /* exception: "Capture Volume" and "Capture Switch" */ - if (!strcmp(name, "Capture Volume")) { - *type = CTL_CAPTURE_VOLUME; - return strlen("Capture"); - } - if (!strcmp(name, "Capture Switch")) { - *type = CTL_CAPTURE_SWITCH; - return strlen("Capture"); - } - /* Special case - handle "Input Source" as a capture route. * Note that it's *NO* capture source. A capture source is split over * sub-elements, and multiple capture-sources will result in an error. -- 2.31.1

2 1

[PATCH] ALSA: hda/realtek: Add fixup for HP OMEN laptop
by Takashi Iwai 04 May '21

04 May '21

HP OMEN dc0019-ur with codec SSID 103c:84da requires the pin config overrides and the existing mic/mute LED setup. This patch implements those in the fixup table. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212733 Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/patch_realtek.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index ee2841dd0c6d..6d58f24c9702 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6506,6 +6506,7 @@ enum { ALC285_FIXUP_IDEAPAD_S740_COEF, ALC285_FIXUP_HP_LIMIT_INT_MIC_BOOST, ALC295_FIXUP_ASUS_DACS, + ALC295_FIXUP_HP_OMEN, }; static const struct hda_fixup alc269_fixups[] = { @@ -8014,6 +8015,26 @@ static const struct hda_fixup alc269_fixups[] = { .type = HDA_FIXUP_FUNC, .v.func = alc295_fixup_asus_dacs, }, + [ALC295_FIXUP_HP_OMEN] = { + .type = HDA_FIXUP_PINS, + .v.pins = (const struct hda_pintbl[]) { + { 0x12, 0xb7a60130 }, + { 0x13, 0x40000000 }, + { 0x14, 0x411111f0 }, + { 0x16, 0x411111f0 }, + { 0x17, 0x90170110 }, + { 0x18, 0x411111f0 }, + { 0x19, 0x02a11030 }, + { 0x1a, 0x411111f0 }, + { 0x1b, 0x04a19030 }, + { 0x1d, 0x40600001 }, + { 0x1e, 0x411111f0 }, + { 0x21, 0x03211020 }, + {} + }, + .chained = true, + .chain_id = ALC269_FIXUP_HP_LINE1_MIC1_LED, + }, }; static const struct snd_pci_quirk alc269_fixup_tbl[] = { @@ -8172,6 +8193,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x82c0, "HP G3 mini premium", ALC221_FIXUP_HP_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x103c, 0x83b9, "HP Spectre x360", ALC269_FIXUP_HP_MUTE_LED_MIC3), SND_PCI_QUIRK(0x103c, 0x8497, "HP Envy x360", ALC269_FIXUP_HP_MUTE_LED_MIC3), + SND_PCI_QUIRK(0x103c, 0x84da, "HP OMEN dc0019-ur", ALC295_FIXUP_HP_OMEN), SND_PCI_QUIRK(0x103c, 0x84e7, "HP Pavilion 15", ALC269_FIXUP_HP_MUTE_LED_MIC3), SND_PCI_QUIRK(0x103c, 0x869d, "HP", ALC236_FIXUP_HP_MUTE_LED), SND_PCI_QUIRK(0x103c, 0x86c7, "HP Envy AiO 32", ALC274_FIXUP_HP_ENVY_GPIO), @@ -8577,6 +8599,7 @@ static const struct hda_model_fixup alc269_fixup_models[] = { {.id = ALC255_FIXUP_XIAOMI_HEADSET_MIC, .name = "alc255-xiaomi-headset"}, {.id = ALC274_FIXUP_HP_MIC, .name = "alc274-hp-mic-detect"}, {.id = ALC245_FIXUP_HP_X360_AMP, .name = "alc245-hp-x360-amp"}, + {.id = ALC295_FIXUP_HP_OMEN, .name = "alc295-hp-omen"}, {} }; #define ALC225_STANDARD_PINS \ -- 2.26.2

1 0

[PATCH v3 0/1] Enable using multiple different type kcontrols for widgets
by Jaska Uimonen 04 May '21

04 May '21

Hi, This is a patch v3 for enabling multiple different types of kcontrols for a dapm widget. Currently asoc allows to define and parse multiple same type kcontrols for single widget. So you can have for example two volume controls in a widget but not one byte and one enum control. Lately we've seen couple of cases where different types of controls would be useful and alsa topology actually allows you to create these. This patch refactors the dapm kcontrol parsing by lifting the creation loop and memory allocation up one level and making the type variable to hold multiple type values. Sof driver is modified to use this type information in the same patch as it is quite cumbersome to split the changes nicely. changes since v2: - only 1 patch for not breaking bisect - sof internal reviews -> minor changes + reviewed by tags - no upstream comments after v2 -> assuming I'm on the right track here Jaska Uimonen (1): ASoC: dapm: Add support for multiple kcontrol types to a widget include/sound/soc-topology.h | 2 +- sound/soc/soc-topology.c | 466 +++++++++++++++++------------------ sound/soc/sof/topology.c | 15 +- 3 files changed, 233 insertions(+), 250 deletions(-) -- 2.24.1

1 1

[PATCH] ALSA: hda/realtek: Fix speaker amp on HP Envy AiO 32
by Takashi Iwai 04 May '21

04 May '21

HP Envy AiO 32-a12xxx has an external amp that is controlled via GPIO bit 0x04. However, unlike other devices, this amp seems to shut down itself after the certain period, hence the OS needs to up/down the bit dynamically only during the actual playback. This patch adds the control of the GPIO bit via the existing pcm_hook mechanism. Ideally it should be triggered at the actual stream start, but we have only the state change at prepare/cleanup, so use those for switching the GPIO bit on/off. This should be good enough for the purpose, and was actually confirmed to work fine. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212873 Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/patch_realtek.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index bbbe37f3e724..ee2841dd0c6d 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4338,6 +4338,35 @@ static void alc245_fixup_hp_x360_amp(struct hda_codec *codec, } } +/* toggle GPIO2 at each time stream is started; we use PREPARE state instead */ +static void alc274_hp_envy_pcm_hook(struct hda_pcm_stream *hinfo, + struct hda_codec *codec, + struct snd_pcm_substream *substream, + int action) +{ + switch (action) { + case HDA_GEN_PCM_ACT_PREPARE: + alc_update_gpio_data(codec, 0x04, true); + break; + case HDA_GEN_PCM_ACT_CLEANUP: + alc_update_gpio_data(codec, 0x04, false); + break; + } +} + +static void alc274_fixup_hp_envy_gpio(struct hda_codec *codec, + const struct hda_fixup *fix, + int action) +{ + struct alc_spec *spec = codec->spec; + + if (action == HDA_FIXUP_ACT_PROBE) { + spec->gpio_mask |= 0x04; + spec->gpio_dir |= 0x04; + spec->gen.pcm_playback_hook = alc274_hp_envy_pcm_hook; + } +} + static void alc_update_coef_led(struct hda_codec *codec, struct alc_coef_led *led, bool polarity, bool on) @@ -6465,6 +6494,7 @@ enum { ALC255_FIXUP_XIAOMI_HEADSET_MIC, ALC274_FIXUP_HP_MIC, ALC274_FIXUP_HP_HEADSET_MIC, + ALC274_FIXUP_HP_ENVY_GPIO, ALC256_FIXUP_ASUS_HPE, ALC285_FIXUP_THINKPAD_NO_BASS_SPK_HEADSET_JACK, ALC287_FIXUP_HP_GPIO_LED, @@ -7907,6 +7937,10 @@ static const struct hda_fixup alc269_fixups[] = { .chained = true, .chain_id = ALC274_FIXUP_HP_MIC }, + [ALC274_FIXUP_HP_ENVY_GPIO] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc274_fixup_hp_envy_gpio, + }, [ALC256_FIXUP_ASUS_HPE] = { .type = HDA_FIXUP_VERBS, .v.verbs = (const struct hda_verb[]) { @@ -8140,6 +8174,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x8497, "HP Envy x360", ALC269_FIXUP_HP_MUTE_LED_MIC3), SND_PCI_QUIRK(0x103c, 0x84e7, "HP Pavilion 15", ALC269_FIXUP_HP_MUTE_LED_MIC3), SND_PCI_QUIRK(0x103c, 0x869d, "HP", ALC236_FIXUP_HP_MUTE_LED), + SND_PCI_QUIRK(0x103c, 0x86c7, "HP Envy AiO 32", ALC274_FIXUP_HP_ENVY_GPIO), SND_PCI_QUIRK(0x103c, 0x8724, "HP EliteBook 850 G7", ALC285_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8729, "HP", ALC285_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8730, "HP ProBook 445 G7", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), -- 2.26.2

1 0