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

[PATCH] ASoC: soc-ac97: fix kernel-doc
by Pierre-Louis Bossart 03 Jul '20

03 Jul '20

Fix W=1 warning. Add missing arguments Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- sound/soc/soc-ac97.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/soc-ac97.c b/sound/soc/soc-ac97.c index 906106ed8ca1..65db083e242b 100644 --- a/sound/soc/soc-ac97.c +++ b/sound/soc/soc-ac97.c @@ -393,6 +393,8 @@ EXPORT_SYMBOL_GPL(snd_soc_set_ac97_ops); /** * snd_soc_set_ac97_ops_of_reset - Set ac97 ops with generic ac97 reset functions + * @ops: bus ops + * @pdev: platform device * * This function sets the reset and warm_reset properties of ops and parses * the device node of pdev to get pinctrl states and gpio numbers to use. -- 2.25.1

2 1

[PATCH][next] ASoC: Intel: bxt-da7219-max98357a: return -EINVAL on unrecognized speaker amplifier
by Colin King 03 Jul '20

03 Jul '20

From: Colin Ian King <colin.king(a)canonical.com> Currently if the ctx->spkamp is not recognized an error message is reported but the code continues to set up the device with uninitialized variables such as the number of widgets. Fix this by returning -EINVAL for unrecognized speaker amplifier types. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: e1435a1feb18 ("ASoC: Intel: bxt-da7219-max98357a: support MAX98390 speaker amp") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- sound/soc/intel/boards/bxt_da7219_max98357a.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/intel/boards/bxt_da7219_max98357a.c b/sound/soc/intel/boards/bxt_da7219_max98357a.c index 4d39253e796b..0c0a717823c4 100644 --- a/sound/soc/intel/boards/bxt_da7219_max98357a.c +++ b/sound/soc/intel/boards/bxt_da7219_max98357a.c @@ -677,7 +677,7 @@ static int bxt_card_late_probe(struct snd_soc_card *card) break; default: dev_err(card->dev, "Invalid speaker amplifier %d\n", ctx->spkamp); - break; + return -EINVAL; } err = snd_soc_dapm_new_controls(&card->dapm, widgets, num_widgets); -- 2.27.0

3 2

[PATCH] ASoC: core: Remove only the registered component in devm functions
by Maxime Ripard 03 Jul '20

03 Jul '20

The ASoC devm_ functions that register a component (devm_snd_soc_register_component and devm_snd_dmaengine_pcm_register) will clean their component by running snd_soc_unregister_component. snd_soc_unregister_component will then remove all the components for the device that was used to register the component in the first place. However, some drivers register several components (such as a DAI and a dmaengine PCM) on the same device, and if the dmaengine PCM is registered first, then the DAI will be cleaned up first and snd_dmaengine_pcm_unregister will be called next. snd_dmaengine_pcm_unregister will then lookup the dmaengine PCM component on the device, and if there's one unregister that component and release its dmaengine channels. That doesn't happen in practice though since the first call to snd_soc_unregister_component removed all the components, so we never get the chance to release the dmaengine channels. In order to fix this, instead of removing all the components for a given device, we can simply remove the component that was registered in the first place. We should have the same number of component registration than we have components, so it should work just fine. Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> --- This was observed on a RaspberryPi that uses the vc4_hdmi driver (drivers/gpu/drm/vc4/vc4_hdmi.c). This driver will register a dmaengine PCM and two components. If the MIPI-DSI controller is enabled, it will create an EPROBE_DEFER across the entire display pipeline, leading to multiple bind/unbind cycles in the other display drivers including vc4_hdmi, leading to multiple warnings since we request the same dmaengine channels on the same device without ever releasing them. It's not really clear to me when that bug was introduced exactly, since it can only be seen on a rather unusual setup, and with all the drivers built-in (otherwise we probably wouldn't get an EPROBE_DEFER for DSI), but it still looks like something that should probably go to stable? --- include/sound/soc.h | 2 ++ sound/soc/soc-core.c | 27 +++++++++++++++++++++++++++ sound/soc/soc-devres.c | 8 +++++--- sound/soc/soc-generic-dmaengine-pcm.c | 2 +- 4 files changed, 35 insertions(+), 4 deletions(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index ef5dd28e10a9..0b3b31803678 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -444,6 +444,8 @@ int devm_snd_soc_register_component(struct device *dev, const struct snd_soc_component_driver *component_driver, struct snd_soc_dai_driver *dai_drv, int num_dai); void snd_soc_unregister_component(struct device *dev); +void snd_soc_unregister_component_by_driver(struct device *dev, + const struct snd_soc_component_driver *component_driver); struct snd_soc_component *snd_soc_lookup_component(struct device *dev, const char *driver_name); diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 7b387202c5db..9d24cbd9111f 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -2571,6 +2571,33 @@ int snd_soc_register_component(struct device *dev, } EXPORT_SYMBOL_GPL(snd_soc_register_component); +/** + * snd_soc_unregister_component_by_driver - Unregister component using a given driver + * from the ASoC core + * + * @dev: The device to unregister + * @component_driver: The component driver to unregister + */ +void snd_soc_unregister_component_by_driver(struct device *dev, + const struct snd_soc_component_driver *component_driver) +{ + struct snd_soc_component *component; + + if (!component_driver) + return; + + mutex_lock(&client_mutex); + component = snd_soc_lookup_component_nolocked(dev, component_driver->name); + if (!component) + goto out; + + snd_soc_del_component_unlocked(component); + +out: + mutex_unlock(&client_mutex); +} +EXPORT_SYMBOL_GPL(snd_soc_unregister_component_by_driver); + /** * snd_soc_unregister_component - Unregister all related component * from the ASoC core diff --git a/sound/soc/soc-devres.c b/sound/soc/soc-devres.c index a9ea172a66a7..c6364caabc0e 100644 --- a/sound/soc/soc-devres.c +++ b/sound/soc/soc-devres.c @@ -11,7 +11,9 @@ static void devm_component_release(struct device *dev, void *res) { - snd_soc_unregister_component(*(struct device **)res); + const struct snd_soc_component_driver **cmpnt_drv = res; + + snd_soc_unregister_component_by_driver(dev, *cmpnt_drv); } /** @@ -28,7 +30,7 @@ int devm_snd_soc_register_component(struct device *dev, const struct snd_soc_component_driver *cmpnt_drv, struct snd_soc_dai_driver *dai_drv, int num_dai) { - struct device **ptr; + const struct snd_soc_component_driver **ptr; int ret; ptr = devres_alloc(devm_component_release, sizeof(*ptr), GFP_KERNEL); @@ -37,7 +39,7 @@ int devm_snd_soc_register_component(struct device *dev, ret = snd_soc_register_component(dev, cmpnt_drv, dai_drv, num_dai); if (ret == 0) { - *ptr = dev; + *ptr = cmpnt_drv; devres_add(dev, ptr); } else { devres_free(ptr); diff --git a/sound/soc/soc-generic-dmaengine-pcm.c b/sound/soc/soc-generic-dmaengine-pcm.c index f728309a0833..ab600be9e69f 100644 --- a/sound/soc/soc-generic-dmaengine-pcm.c +++ b/sound/soc/soc-generic-dmaengine-pcm.c @@ -490,7 +490,7 @@ void snd_dmaengine_pcm_unregister(struct device *dev) pcm = soc_component_to_pcm(component); - snd_soc_unregister_component(dev); + snd_soc_unregister_component_by_driver(dev, component->driver); dmaengine_pcm_release_chan(pcm); kfree(pcm); } -- 2.26.2

2 1

Xone32c bNumConfigurations issue
by Tim Nugent 03 Jul '20

03 Jul '20

Hi alsa-devel, Having a few problems with the Xone32c though not sure if this is an ALSA issue or general USB stack problem. It's a USB soundcard that is supposed to have 4 inputs and 4 outputs. It seems to have 2 USB configurations (bNumConfigurations : 0x2). When plugged in, bConfigurationValue is 0x1 and only 2 inputs and 2 outputs show up. Change this value to 0x2 and it shows up (as it should) as 4 inputs and 4 outputs. Here's the full USB description: https://pastebin.com/DDPXv5c1 I can change the bConfigurationValue with this udev rule, or with a `echo 2 > /sys/bus/usb/devices/1-1.4/bConfigurationValue`: https://gist.github.com/timnugent/ed65a79b2bd6c63788bfada3624756a4 This has all been working OK on Ubuntu 20.04 running kernel 5.4.0-33-generic. However, I just updated to 5.4.0-37-generic and now there is only a single USB configuration (bNumConfigurations : 0x1) and bConfigurationValue can't be changed to 0x2: https://pastebin.com/th9VRH0q echo 2 > /sys/bus/usb/devices/1-1.4/bConfigurationValue bash: echo: write error: Invalid argument So this could be a regression in snd_usb_audio, or maybe usbhid - which `lsudb -t` says are the drivers. This behaviour (only 1 configuration) also happens on a Raspberry Pi (Raspbian 4.19.66-v7+) - I haven't been able to get it to work at all. Thanks Tim

1 0

[PATCH 00/11] ASoC: codecs: fix kernel-doc and W=1 warnings
by Pierre-Louis Bossart 03 Jul '20

03 Jul '20

Second batch of cleanups to remove all the warnings reported by buildbots/compile tests. Pierre-Louis Bossart (11): ASoC: codecs: ak4458: fix 'set but not used' warning ASoC: codecs: cros_ec_codec: fix 'defined but not used' warning ASoC: codecs: da7210: fix kernel-doc ASoC: codecs: da7219: fix 'defined but not used' warning ASoC: codecs: es8316: fix 'defined but not used' warning ASoC: codecs: max98390: fix 'defined but not used' warning ASoC: codecs: rt*: fix 'defined but not used' warning ASoC: codecs: rt5659: add _maybe_unused as needed ASoC: codecs: rt5631: fix kernel-doc ASoC: codecs: tlv320aic26: fix kernel-doc warning ASoC: codecs: jz4770: add _maybe_unused as needed sound/soc/codecs/ak4458.c | 2 +- sound/soc/codecs/cros_ec_codec.c | 2 ++ sound/soc/codecs/da7210.c | 12 +++++++----- sound/soc/codecs/da7219.c | 2 ++ sound/soc/codecs/es8316.c | 2 ++ sound/soc/codecs/jz4770.c | 2 +- sound/soc/codecs/max98390.c | 8 -------- sound/soc/codecs/rt274.c | 2 ++ sound/soc/codecs/rt286.c | 2 ++ sound/soc/codecs/rt298.c | 2 ++ sound/soc/codecs/rt5631.c | 8 ++++++-- sound/soc/codecs/rt5659.c | 14 +++++++------- sound/soc/codecs/rt5660.c | 2 ++ sound/soc/codecs/rt5677-spi.c | 2 ++ sound/soc/codecs/tlv320aic26.c | 2 +- 15 files changed, 39 insertions(+), 25 deletions(-) base-commit: a2b782d59c57cb6f673dbb4804ffc500336d7a54 -- 2.25.1

2 14

[HDAudio][ALC295] speakers not working on Acer Travelmate P614
by Stanislav Kazmin 03 Jul '20

03 Jul '20

Hello, I have the following problem on my Acer TravelMate P614-51T-G2: I have all the audio sinks correctly identified (like HDMI, DMic, Headphones) but the internal speakers do not produce any sound. What I have tried so far: - hard/soft shutdown on Windows and reboot - disable/re-enable speakers and microphone in BIOS - uninstall pulseaudio and test alsa alone (so it is defeitely **not** a pulseaudio issue) - switch from sof-hda-dsp to snd-hda-intel driver (without Dmic support) - retask pins 0x14, 0x16, 0x1b to "Internal Speakers" through hdajackretask (only basic, without advanced features) - removed/reconnected the headphones `alsamixer` shows all needed sinks and nothing is muted. I already discussed the issue at sof github https://github.com/thesofproject/ sof/issues/3058 but since the same issue occurs on `snd-hda-intel` legacy river, I was advised to communicate with alsa-devel team. The alsa-info.sh result are linked at http://alsa-project.org/db/? f=252f92c7a1df3c755d16ee69353b26d2535a4d81 I have tested the kernel 5.8-rc1 but it does not make any difference. Let me know if I can do anything else to test the issue.

2 5

[PATCH 0/2] ASoC: fsl-asoc-card: add support for generic codecs
by Arnaud Ferraris 03 Jul '20

03 Jul '20

fsl-asoc-card currently only works with AC97 or a selection of codecs, although the hardware is capable of more. Supporting generic codecs when acting as I2S slave (codec is master) would be useful, especially when using Bluetooth audio, as these are generally simple I2S devices not controlled by the sound subsystem. This will allow using simple/dummy codecs along with ASRC. Arnaud Ferraris (2): dt-bindings: sound: fsl-asoc-card: add new compatible for I2S slave ASoC: fsl-asoc-card: add support for generic I2S slave use-case Documentation/devicetree/bindings/sound/fsl-asoc-card.txt | 23 ++++++++++++++++++++++- sound/soc/fsl/fsl-asoc-card.c | 46 +++++++++++++++++++++++++++++++++++----------- 2 files changed, 57 insertions(+), 12 deletions(-)

2 6

How to identify Alsa eLements?
by Tanjeff Moos 03 Jul '20

03 Jul '20

Hi alsa-devel, I'm programming a GUI for the mixer in my Focusrite Scarlett 6i6 interface. The Alsa driver supports that functionality, i.e. I can control the mixer using alsamixer, for example. Now I'm writing a Qt GUI for it. I wonder how I can reliably identify a mixer control element (e.g. the master volume control). Each element has an ID (struct snd_ctl_elem_id), consisting of multiple elements: - numid (seems to change at each boot) - iface - device - subdevice - name (is always constant) - index The docs says I can identify an element by the combination of name and index. My questions: 1) Are name and index enough to identify an element? 2) How can I obtain the index? The name and numid are shown by 'amixer contents', for example. Kind regards, Tanjeff

2 4

sof-hda-dsp UCM doesn't work with the latest alsa-lib
by GitHub issues - opened 03 Jul '20

03 Jul '20

alsa-project/alsa-lib issue #67 was opened from libinyang: In the latest UCM for sof-hda-dsp, it has supported Syntax 3 and it uses $var for hdmi. In sof-hda-dsp/Hdmi.conf, It defines "HdmiNum 1", and later it will redefine "HdmiNum 2", then "HdmiNum 3". It will try to `Include.hdmi1.File "/codecs/hda/hdmi.conf"` to use these definitions. But actually, only "HdmiNum 3" will be used for HDMI1, HDMI2 and HDMI3. The old value of "1" and "2" will be overridden when parsing HDMI1 and HDMI2. This is the bug of alsa-lib initialization sequence issue. HDA-Intel/Hdmi.conf should have the same issue. Issue URL : https://github.com/alsa-project/alsa-lib/issues/67 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH RFC alsa-ucm-conf] sof-hda-dsp: Use Master mixer to control volume with dual stereo speakers
by Benjamin Poirier 03 Jul '20

03 Jul '20

The Lenovo ThinkPad X1 Carbon 7th is a laptop with two sets of stereo speakers driven from a single stereo output. The volume of each set of speakers can be controlled independently through two separate mixers. In that case, one of those mixers serves a dual purpose: it also controls headphone volume. With the current ucm profile, when outputting to speakers, pulseaudio uses only the mixer for the front speakers to control volume. This is ineffective; rear speaker volume must be controlled as well. In order to control both sets of speakers at once, indicate that the Master mixer should be used. Moreover, when switching between speaker and headphone outputs, the level of the dual purpose mixer should be restored. Since this kind of constraint cannot be described with ucm, indicate that the Master mixer should be used to control volume instead when outputting to headphones. This patch depends on a modification to the snd_hda_codec_realtek kernel driver used on that system to rename one of the controls. Signed-off-by: Benjamin Poirier <benjamin.poirier(a)gmail.com> --- Note that I plan to submit the related kernel patch upstream shortly, in the meantime, it is available here: https://github.com/gobenji/thinkpad-x1-gen7-sound Also note that this patch is based on commit 38e5906cd1b1 ("sof-hda-dsp: fix the device order (Hdmi devices)"). While testing with libasound built from alsa-lib git head 485930ea5dc8 ("ucm: substitution - remove duplicate allow_empty assignment"), alsa-ucm-conf versions including dcef48f13d4f ("HDA-Intel: add support for AMD acp microphone devices") and newer do not work for me. I've tested up to current head, ffe0cab5cfce ("sof-hda-dsp: use sof-hda-dsp/Hdmi.conf"). Looking at the output of `pulseaudio --log-level=debug`, things go wrong at: I: [pulseaudio] (alsa-lib)main.c: error: failed to import sof-hda-dsp use case configuration -17 ucm2/sof-hda-dsp/HiFi.conf | 32 ++++++++++++++++++++++++++++---- 1 file changed, 28 insertions(+), 4 deletions(-) diff --git a/ucm2/sof-hda-dsp/HiFi.conf b/ucm2/sof-hda-dsp/HiFi.conf index 62358e2..661a086 100644 --- a/ucm2/sof-hda-dsp/HiFi.conf +++ b/ucm2/sof-hda-dsp/HiFi.conf @@ -25,10 +25,22 @@ SectionDevice."Headphones" { Value { PlaybackPriority 200 PlaybackPCM "hw:${CardId}" - PlaybackMixerElem "Headphone" PlaybackMasterElem "Master" - PlaybackVolume "Headphone Playback Volume" PlaybackSwitch "Headphone Playback Switch" + If.hpmixer { + Condition { + Type ControlExists + Control "name='Headphone/Bass Speaker Playback Volume'" + } + True { + PlaybackMixerElem "Master" + PlaybackVolume "Master Playback Volume" + } + False { + PlaybackMixerElem "Headphone" + PlaybackVolume "Headphone Playback Volume" + } + } If.jack { Condition { Type ControlExists @@ -77,10 +89,22 @@ SectionDevice."Speaker" { Value { PlaybackPriority 100 PlaybackPCM "hw:${CardId}" - PlaybackMixerElem "Speaker" PlaybackMasterElem "Master" - PlaybackVolume "Speaker Playback Volume" PlaybackSwitch "Speaker Playback Switch" + If.spkmixer { + Condition { + Type ControlExists + Control "name='Headphone/Bass Speaker Playback Volume'" + } + True { + PlaybackMixerElem "Master" + PlaybackVolume "Master Playback Volume" + } + False { + PlaybackMixerElem "Speaker" + PlaybackVolume "Speaker Playback Volume" + } + } } } -- 2.27.0

1 0