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

[alsa-devel] axfer: test: fix invalid comparison of 64 bit storage in ILP32 data type
by GitHub pull_request - opened 28 Jul '19

28 Jul '19

alsa-project/alsa-utils pull request #25 was opened from takaswie: In system V ABIs with ILP32 data model, bit shift for '1ul' can brings undefined behaviour when the calculation result is over 32 bit width. This commit fixes the bug. Reported-by: Rolf Eike Beer <eike(a)sf-mail.de> Reference: https://bugs.gentoo.org/681652 Reference: https://github.com/alsa-project/alsa-utils/issues/23 Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> Request URL : https://github.com/alsa-project/alsa-utils/pull/25 Patch URL : https://github.com/alsa-project/alsa-utils/pull/25.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

[alsa-devel] axfer: mapper: fix parameter check for demuxer
by GitHub pull_request - opened 28 Jul '19

28 Jul '19

alsa-project/alsa-utils pull request #24 was opened from takaswie: Each container should be configured to store one saple per frame in demuxer case. This commit fixes the bug. Fixes: 25c8e3bebb53 ('axfer: add support for a mapper for multiple target') Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> Request URL : https://github.com/alsa-project/alsa-utils/pull/24 Patch URL : https://github.com/alsa-project/alsa-utils/pull/24.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

[alsa-devel] axfr/tests fail on hppa and sparc
by GitHub issues - opened 27 Jul '19

27 Jul '19

alsa-project/alsa-utils issue #23 was opened from DerDakon: There is a Gentoo bug about this test failures: https://bugs.gentoo.org/681652 The log on hppa says this: ``` ================================================= alsa-utils 1.1.9: axfer/test/test-suite.log ================================================= # TOTAL: 2 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 2 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: container-test ==================== container-test: container-test.c:53: test_builder: Assertion `err == 0' failed. FAIL container-test (exit status: 134) FAIL: mapper-test ================= Invalid argument FAIL mapper-test (exit status: 1) ``` The errors are similar on sparc. Does that depend on specific kernel features to be enabled? Also note that both architectures are big endian, which may or may not be related. Issue URL : https://github.com/alsa-project/alsa-utils/issues/23 Repository URL: https://github.com/alsa-project/alsa-utils

1 0

[alsa-devel] [PATCH] ALSA: usb-audio: fix PCM device order
by Alexander Tsoy 27 Jul '19

27 Jul '19

Some cards have alternate setting with non-PCM format as the first altsetting in the interface descriptors. This confuses userspace, since alsa-lib uses device 0 by default. So lets parse interfaces in two steps: 1. Parse altsettings with PCM formats. 2. Parse altsettings with non-PCM formats. This fixes at least following cards: - Audinst HUD-mx2 - Audinst HUD-mini Signed-off-by: Alexander Tsoy <alexander(a)tsoy.me> --- sound/usb/stream.c | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/sound/usb/stream.c b/sound/usb/stream.c index 8e9548bc1f1a..b2ebeae91396 100644 --- a/sound/usb/stream.c +++ b/sound/usb/stream.c @@ -477,7 +477,8 @@ static struct uac2_output_terminal_descriptor * return NULL; } -int snd_usb_parse_audio_interface(struct snd_usb_audio *chip, int iface_no) +static int __snd_usb_parse_audio_interface(struct snd_usb_audio *chip, int iface_no, + bool *has_non_pcm, bool non_pcm) { struct usb_device *dev; struct usb_interface *iface; @@ -634,6 +635,10 @@ int snd_usb_parse_audio_interface(struct snd_usb_audio *chip, int iface_no) iface_no, altno); continue; } + if (fmt->bFormatType != UAC_FORMAT_TYPE_I) + *has_non_pcm = true; + if ((fmt->bFormatType == UAC_FORMAT_TYPE_I) == non_pcm) + continue; if (((protocol == UAC_VERSION_1) && (fmt->bLength < 8)) || ((protocol == UAC_VERSION_2) && (fmt->bLength < 6))) { dev_err(&dev->dev, @@ -740,3 +745,23 @@ int snd_usb_parse_audio_interface(struct snd_usb_audio *chip, int iface_no) return 0; } +int snd_usb_parse_audio_interface(struct snd_usb_audio *chip, int iface_no) +{ + int err; + bool has_non_pcm = false; + + /* parse PCM formats */ + err = __snd_usb_parse_audio_interface(chip, iface_no, &has_non_pcm, false); + if (err < 0) + return err; + + if (has_non_pcm) { + /* parse non-PCM formats */ + err = __snd_usb_parse_audio_interface(chip, iface_no, &has_non_pcm, true); + if (err < 0) + return err; + } + + return 0; +} + -- 2.13.0

3 2

[alsa-devel] Plugged in headphones ignored
by Paul Menzel 27 Jul '19

27 Jul '19

Dear Linux folks, On a Dell OptiPlex 5040 with Linux 5.2-rc6 plugging in a head phone into the front case connector, it is detected just fine and Xfce shows a notification. Then logging out, turning off the monitor connected over DisplayPort at the end of the day, and turning the monitor back on the next morning, logging in, the state is forgotten. I need to unplug the head phone and plug it back in. Please find the output alsa-config.sh for the non-working (1) and replugged (2) situations attached. Is that a Linux kernel problem, or a user space issue? Kind regards, Paul

2 2

[alsa-devel] [PATCHv2] hda: Fix 1-minute detection delay when i915 module is not available
by Samuel Thibault 27 Jul '19

27 Jul '19

Distribution installation images such as Debian include different sets of modules which can be downloaded dynamically. Such images may notably include the hda sound modules but not the i915 DRM module, even if the latter was enabled at build time, as reported on https://bugs.debian.org/931507 In such a case hdac_i915 would be linked in and try to load the i915 module, fail since it is not there, but still wait for a whole minute before giving up binding with it. This fixes such as case by only waiting for the binding if the module was properly loaded (or module support is disabled, in which case i915 is already compiled-in anyway). Signed-off-by: Samuel Thibault <samuel.thibault(a)ens-lyon.org> --- sound/hda/hdac_i915.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) --- a/sound/hda/hdac_i915.c +++ b/sound/hda/hdac_i915.c @@ -136,10 +136,13 @@ int snd_hdac_i915_init(struct hdac_bus * if (!acomp) return -ENODEV; if (!acomp->ops) { - request_module("i915"); - /* 60s timeout */ - wait_for_completion_timeout(&bind_complete, - msecs_to_jiffies(60 * 1000)); + if (!IS_ENABLED(CONFIG_MODULES) || + !request_module("i915")) + { + /* 60s timeout */ + wait_for_completion_timeout(&bind_complete, + msecs_to_jiffies(60 * 1000)); + } } if (!acomp->ops) { dev_info(bus->dev, "couldn't bind with audio component\n");

2 1

[alsa-devel] [PATCH v2 0/5] ALSA/HDA: abort probe when DMICs are detected
by Pierre-Louis Bossart 27 Jul '19

27 Jul '19

This is the second take on same problem of detecting when the HDaudio legacy driver can be used and when the SST or SOF drivers are required. The previous attempt based on a the PCI Class information was a resounding failure and broke audio on Linus' laptop, so we need additional information to avoid enabling a DSP-based driver without a good reason to do so. This patchset suggests the use of the NHLT information which *in theory* exposes DMIC endpoints. The legacy HDaudio driver cannot handle DMICs and will not provide any capture capabilities. Since it's typically the first one to probe due to the Makefile order, aborting the probe will let the PCI subsystem look for the next driver which hopefully will support this capability. I tested this patch on 5 devices (SKL, KBL, APL, GLK, WHL), three without DMICs and two with, and the detection seems to work as planned. Additional testing by Canonical and Endless folks did not expose any issues. Changes since v1 (Feedback from Takashi): Squashed patch3 in patch2 Changed log to dbg_info Fixed module parameter handling Changes since RFC: Cosmetic code improvements Moved intel-nhlt.h to include/sound Moved intel-nhlt.c to sound/hda Removed SOC prefixes Added full-support for vendor-defined geometries Added Kconfig and kernel module parameter to opt-in Pierre-Louis Bossart (5): ASoC: Intel: Skylake: move NHLT header to common directory ALSA: hda: move parts of NHLT code to new module ALSA: hda: intel-nhlt: handle NHLT VENDOR_DEFINED DMIC geometry ASoC: Intel: Skylake: use common NHLT module ALSA: hda/intel: stop probe if DMICS are detected on Skylake+ platforms .../skl-nhlt.h => include/sound/intel-nhlt.h | 51 +++++++-- sound/hda/Kconfig | 3 + sound/hda/Makefile | 3 + sound/hda/intel-nhlt.c | 102 ++++++++++++++++++ sound/pci/hda/Kconfig | 10 ++ sound/pci/hda/hda_intel.c | 34 ++++++ sound/soc/intel/Kconfig | 1 + sound/soc/intel/skylake/skl-nhlt.c | 91 +--------------- sound/soc/intel/skylake/skl-ssp-clk.c | 1 + sound/soc/intel/skylake/skl-topology.c | 1 + sound/soc/intel/skylake/skl.c | 12 ++- sound/soc/intel/skylake/skl.h | 4 - 12 files changed, 205 insertions(+), 108 deletions(-) rename sound/soc/intel/skylake/skl-nhlt.h => include/sound/intel-nhlt.h (65%) create mode 100644 sound/hda/intel-nhlt.c -- 2.20.1

3 13

[alsa-devel] hda: Fix 1-minute detection delay when i915 module is not available
by Samuel Thibault 26 Jul '19

26 Jul '19

Distribution installation images such as Debian include different sets of modules which can be downloaded dynamically. Such images may notably include the hda sound modules but not the i915 DRM module, even if the latter was enabled at build time, as reported on https://bugs.debian.org/931507 In such a case hdac_i915 would be linked in and try to load the i915 module, fail since it is not there, but still wait for a whole minute before giving up binding with it. This fixes such as case by only waiting for the binding if the module was properly loaded (or module support is disabled, in which case i915 is already compiled-in anyway). Signed-off-by: Samuel Thibault <samuel.thibault(a)ens-lyon.org> --- sound/hda/hdac_i915.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) --- a/sound/hda/hdac_i915.c +++ b/sound/hda/hdac_i915.c @@ -143,10 +143,14 @@ int snd_hdac_i915_init(struct hdac_bus * if (!acomp) return -ENODEV; if (!acomp->ops) { - request_module("i915"); - /* 60s timeout */ - wait_for_completion_timeout(&bind_complete, - msecs_to_jiffies(60 * 1000)); +#ifdef CONFIG_MODULES + if (request_module("i915") == 0) +#endif + { + /* 60s timeout */ + wait_for_completion_timeout(&bind_complete, + msecs_to_jiffies(60 * 1000)); + } } if (!acomp->ops) { dev_info(bus->dev, "couldn't bind with audio component\n");

2 1

[alsa-devel] [PATCH v4 0/1] Fix driver reload issues
by Amadeusz Sławiński 26 Jul '19

26 Jul '19

Hi, this is last patch left from series fixing driver reload problems. Rebased onto latest for-next in Marks tree. Amadeusz Sławiński (1): ASoC: Intel: Skylake: Remove static table index when parsing topology sound/soc/intel/skylake/skl-topology.c | 34 +++++++++----------------- 1 file changed, 12 insertions(+), 22 deletions(-) -- 2.17.1

2 2

[alsa-devel] [PATCH v3 0/5] ALSA/HDA: abort probe when DMICs are detected
by Pierre-Louis Bossart 26 Jul '19

26 Jul '19

This is the second take on same problem of detecting when the HDaudio legacy driver can be used and when the SST or SOF drivers are required. The previous attempt based on a the PCI Class information was a resounding failure and broke audio on Linus' laptop, so we need additional information to avoid enabling a DSP-based driver without a good reason to do so. This patchset suggests the use of the NHLT information which *in theory* exposes DMIC endpoints. The legacy HDaudio driver cannot handle DMICs and will not provide any capture capabilities. Since it's typically the first one to probe due to the Makefile order, aborting the probe will let the PCI subsystem look for the next driver which hopefully will support this capability. I tested this patch on 5 devices (SKL, KBL, APL, GLK, WHL), three without DMICs and two with, and the detection seems to work as planned. Additional testing by Canonical and Endless folks did not expose any issues. Changes since v2 (Feedback from Takahi and Cezary) Added comment in Kconfig to alert the user to the dependency on ACPI Changes since v1 (Feedback from Takashi): Squashed patch3 in patch2 Changed log to dbg_info Fixed module parameter handling Changes since RFC: Cosmetic code improvements Moved intel-nhlt.h to include/sound Moved intel-nhlt.c to sound/hda Removed SOC prefixes Added full-support for vendor-defined geometries Added Kconfig and kernel module parameter to opt-in Pierre-Louis Bossart (5): ASoC: Intel: Skylake: move NHLT header to common directory ALSA: hda: move parts of NHLT code to new module ALSA: hda: intel-nhlt: handle NHLT VENDOR_DEFINED DMIC geometry ASoC: Intel: Skylake: use common NHLT module ALSA: hda/intel: stop probe if DMICS are detected on Skylake+ platforms .../skl-nhlt.h => include/sound/intel-nhlt.h | 51 +++++++-- sound/hda/Kconfig | 5 + sound/hda/Makefile | 3 + sound/hda/intel-nhlt.c | 102 ++++++++++++++++++ sound/pci/hda/Kconfig | 10 ++ sound/pci/hda/hda_intel.c | 34 ++++++ sound/soc/intel/Kconfig | 1 + sound/soc/intel/skylake/skl-nhlt.c | 91 +--------------- sound/soc/intel/skylake/skl-ssp-clk.c | 1 + sound/soc/intel/skylake/skl-topology.c | 1 + sound/soc/intel/skylake/skl.c | 12 ++- sound/soc/intel/skylake/skl.h | 4 - 12 files changed, 207 insertions(+), 108 deletions(-) rename sound/soc/intel/skylake/skl-nhlt.h => include/sound/intel-nhlt.h (65%) create mode 100644 sound/hda/intel-nhlt.c -- 2.20.1

2 7