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

[BUG] ALSA: usb-audio: Scarlett 2 mixer driver fails on ehci-pci
by Geoffrey D. Bennett 20 May '21

20 May '21

Hi there, I'm trying to track down an issue with my Scarlett Gen 2 mixer driver that has been reported by a few people, and I can now reliably reproduce the issue, but I need some help in figuring out where exactly the issue is and how to fix it please. The issue only occurs when attempting to use the interface on a USB port using ehci-pci. xhci_hcd USB ports work fine. The issue occurs when sending the first vendor-specific USB command, but only when sending from the kernel driver. Sending the same USB packets from user-space works fine(!). I did initially think that the fault could have been due to earlier USB messages putting the device into a state where it would reject the vendor-specific USB commands, but I have carefully ruled that out & have gotten identical usbmon traces from device power-on up until the device responds differently, the only difference beforehand being whether the USB packet was sent from the kernel driver or user-space. The messages look like this in "usbmon -s 10000 -fu" when sent from user-space (or when sent from the kernel driver when the interface is plugged in to an xhci_hcd port): ffff888125855200 1006026497 S Ci:2:040:0 s a1 00 0000 0005 0018 24 < ffff888125855200 1006026680 C Ci:2:040:0 0 24 = 66191018 73190604 01000000 01000000 00040000 00000000 And like this when sent from the kernel driver when the interface is plugged in to an ehci-pci port: ffff88810487a300 3686673995 S Ci:2:036:0 s a1 00 0000 0005 0018 24 < ffff88810487a300 3692178724 C Ci:2:036:0 -2 0 Identical messages sent according to usbmon, but they must be different somehow! The kernel code to send that message looks like this: return snd_usb_ctl_msg( dev, usb_sndctrlpipe(dev, 0), usb_req, USB_RECIP_INTERFACE | USB_TYPE_CLASS | USB_DIR_IN, 0, interface, buf, size); and helper.c snd_usb_ctl_msg() then calls usb_control_msg(). For sending arbitrary USB packets from user-space for testing, I'm using libusb and: int ret = usb_control_msg( devh, reqtype, request, value, index, buf, size, 1000 ); So, I presume usbmon isn't giving me the full story? How can I determine the difference between the kernel and the user-space usb_control_msg() functions? I see that I can #define EHCI_URB_TRACE in ehci-hcd.c. Can anyone with more experience than me let me know if I'm going in the right direction to track this down? Thanks, Geoffrey.

2 5

Add UCMs for Google Asus Nexus 7 and Acer Iconia A500
by GitHub pull_request - edited 20 May '21

20 May '21

alsa-project/alsa-ucm-conf pull request #92 was edited from digetx: @perexg As was discussed previouly at https://www.spinics.net/lists/alsa-devel/msg126382.html I'm opening PR with the UCMs for Nexus 7 and A500. Both these devices are supported by the mainline Linux kernel. You're right that Tegra ASoC driver doesn't set card's name properly. In particular I found that we need to set the card's `driver_name` to `tegra`, then UCM get a proper lookup path. I rebased UCMs on top of the recent alsa-ucm-conf master and switched Nexus 7 UCM to use generic RT5640 UCM. Everything works great once the card name of the kernel driver is corrected. I'll send the kernel patches ASAP for review. Nexus 7 alsa-info: https://alsa-project.org/db/?f=0a29f1dab39ec5b33e01215dee42dbfd1dbbf08e A500 alsa-info: https://alsa-project.org/db/?f=bde4f7938a39b1d26904b414969fc811e726242f The alsa-info is taken using the updated kernel ASoC driver. Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/92 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/92.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Add UCMs for Google Asus Nexus 7 and Acer Iconial A500
by GitHub pull_request - opened 20 May '21

20 May '21

alsa-project/alsa-ucm-conf pull request #92 was opened from digetx: @perexg As was discussed previouly at https://www.spinics.net/lists/alsa-devel/msg126382.html I'm opening PR with the UCMs for Nexus 7 and A500. Both these devices are supported by the mainline Linux kernel. You're right that Tegra ASoC driver doesn't set card's name properly. In particular I found that we need to set the card's `driver_name` to `tegra`, then UCM get a proper lookup path. I rebased UCMs on top of the recent alsa-ucm-conf master and switched Nexus 7 UCM to use generic RT5640 UCM. Everything works great once the card name of the kernel driver is corrected. I'll send the kernel patches ASAP for review. Nexus 7 alsa-info: https://alsa-project.org/db/?f=0a29f1dab39ec5b33e01215dee42dbfd1dbbf08e A500 alsa-info: https://alsa-project.org/db/?f=bde4f7938a39b1d26904b414969fc811e726242f The alsa-info is taken using the updated kernel ASoC driver. Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/92 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/92.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

re: ALSA: usb-audio: Handle error for the current selector gracefully [ uninitialized variable issue ]
by Colin Ian King 20 May '21

20 May '21

Hi, Static analysis with Coverity on linux-next has detected an uninitialized variable issue with the following commit: commit 481f17c41803985446fd12887b2c042f9c43b0d5 Author: Takashi Iwai <tiwai(a)suse.de> Date: Tue May 18 17:21:12 2021 +0200 ALSA: usb-audio: Handle error for the current selector gracefully The branching is a bit convoluted and we end up with variable cur not being initialized. Analysis is as follows: 254static int __uac_clock_find_source(struct snd_usb_audio *chip, 255 const struct audioformat *fmt, int entity_id, 256 unsigned long *visited, bool validate) 257{ 258 union uac23_clock_source_desc *source; 259 union uac23_clock_selector_desc *selector; 260 union uac23_clock_multiplier_desc *multiplier; 1. var_decl: Declaring variable cur without initializer. 261 int ret, i, cur, err, pins, clock_id; 262 const u8 *sources; 263 int proto = fmt->protocol; 264 265 entity_id &= 0xff; 266 2. Condition test_and_set_bit(entity_id, visited), taking false branch. 267 if (test_and_set_bit(entity_id, visited)) { 268 usb_audio_warn(chip, 269 "%s(): recursive clock topology detected, id %d.\n", 270 __func__, entity_id); 271 return -EINVAL; 272 } 273 274 /* first, see if the ID we're looking for is a clock source already */ 275 source = snd_usb_find_clock_source(chip, entity_id, proto); 3. Condition source, taking false branch. 276 if (source) { 277 entity_id = GET_VAL(source, proto, bClockID); 278 if (validate && !uac_clock_source_is_valid(chip, fmt, 279 entity_id)) { 280 usb_audio_err(chip, 281 "clock source %d is not valid, cannot use\n", 282 entity_id); 283 return -ENXIO; 284 } 285 return entity_id; 286 } 287 288 selector = snd_usb_find_clock_selector(chip, entity_id, proto); 4. Condition selector, taking true branch. 289 if (selector) { 5. Condition proto == 48, taking true branch. 290 pins = GET_VAL(selector, proto, bNrInPins); 6. Condition proto == 48, taking true branch. 291 clock_id = GET_VAL(selector, proto, bClockID); 7. Condition proto == 48, taking true branch. 292 sources = GET_VAL(selector, proto, baCSourceID); 293 8. Condition pins == 1, taking false branch. 294 if (pins == 1) { 295 ret = 1; 296 goto find_source; 297 } 298 299 /* the entity ID we are looking for is a selector. 300 * find out what it currently selects */ 301 ret = uac_clock_selector_get_val(chip, clock_id); 9. Condition ret < 0, taking true branch. 302 if (ret < 0) { 10. Condition !chip->autoclock, taking false branch. 303 if (!chip->autoclock) 304 return ret; 11. Jumping to label find_others. 305 goto find_others; 306 } 307 308 /* Selector values are one-based */ 309 310 if (ret > pins || ret < 1) { 311 usb_audio_err(chip, 312 "%s(): selector reported illegal value, id %d, ret %d\n", 313 __func__, clock_id, ret); 314 315 if (!chip->autoclock) 316 return -EINVAL; 317 ret = 0; 318 goto find_others; 319 } 320 321 find_source: 322 cur = ret; 323 ret = __uac_clock_find_source(chip, fmt, 324 sources[ret - 1], 325 visited, validate); 326 if (ret > 0) { 327 err = uac_clock_selector_set_val(chip, entity_id, cur); 328 if (err < 0) 329 return err; 330 } 331 332 if (!validate || ret > 0 || !chip->autoclock) 333 return ret; 334 335 find_others: 336 /* The current clock source is invalid, try others. */ 12. Condition i <= pins, taking true branch. 337 for (i = 1; i <= pins; i++) { Uninitialized scalar variable (UNINIT) 13. uninit_use: Using uninitialized value cur. 338 if (i == cur) 339 continue; 340 Colin

2 1

[PATCH 0/8] ALSA: firewire-lib: start processing content of packet at the same cycle in several contexts for each direction
by Takashi Sakamoto 20 May '21

20 May '21

Hi, Within devices supported by drivers in ALSA firewire stack, only DICE ASICs support several pair of isochronous packet streams. As long as I experienced, the ASIC requires drivers to transfer packets at the same isochronous cycle. Unless, it generates no sound. Additionally, in future integration I have a plan to take drivers performing sequence replay for media clock recovery. It's convenient to manage the cycle to start processing content of packet in several IR contexts. This patchset is to start processing content of packet at the same cycle in several contexts for each direction, including code refactoring. Takashi Sakamoto (8): ALSA: firewire-lib: code refactoring for size of CIP header ALSA: firewire-lib: code refactoring for calculation of context payload ALSA: firewire-lib: code refactoring for selection of IT context header length ALSA: firewire-lib: start processing content of packet at the same cycle in several IR contexts ALSA: firewire-lib: skip initial packets instead of scheduling IR context ALSA: firewire-lib: code refactoring to start several IT/IR contexts ALSA: firewire-lib: start processing content of packet at the same cycle in several IT contexts ALSA: firewire-lib: change waking up timing to process packets sound/firewire/amdtp-stream.c | 492 ++++++++++++++------ sound/firewire/amdtp-stream.h | 53 ++- sound/firewire/bebob/bebob_stream.c | 29 +- sound/firewire/dice/dice-stream.c | 15 +- sound/firewire/digi00x/digi00x-stream.c | 7 +- sound/firewire/fireface/ff-stream.c | 7 +- sound/firewire/fireworks/fireworks_stream.c | 8 +- sound/firewire/motu/amdtp-motu.c | 9 +- sound/firewire/motu/motu-stream.c | 7 +- sound/firewire/oxfw/oxfw-stream.c | 14 +- sound/firewire/tascam/tascam-stream.c | 7 +- 11 files changed, 401 insertions(+), 247 deletions(-) -- 2.27.0

2 9

[PATCH 1/2] ASoC: topology: Fix some error codes in soc_tplg_dapm_widget_create()
by Dan Carpenter 20 May '21

20 May '21

Return -ENOMEM if these allocations fail. (The current code returns success). Fixes: d29d41e28eea ("ASoC: topology: Add support for multiple kcontrol types to a widget") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> --- sound/soc/soc-topology.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/sound/soc/soc-topology.c b/sound/soc/soc-topology.c index e71d98d7b116..6b7a813bc264 100644 --- a/sound/soc/soc-topology.c +++ b/sound/soc/soc-topology.c @@ -1481,13 +1481,17 @@ static int soc_tplg_dapm_widget_create(struct soc_tplg *tplg, template.num_kcontrols = le32_to_cpu(w->num_kcontrols); kc = devm_kcalloc(tplg->dev, le32_to_cpu(w->num_kcontrols), sizeof(*kc), GFP_KERNEL); - if (!kc) + if (!kc) { + ret = -ENOMEM; goto err; + } kcontrol_type = devm_kcalloc(tplg->dev, le32_to_cpu(w->num_kcontrols), sizeof(unsigned int), GFP_KERNEL); - if (!kcontrol_type) + if (!kcontrol_type) { + ret = -ENOMEM; goto err; + } for (i = 0; i < w->num_kcontrols; i++) { control_hdr = (struct snd_soc_tplg_ctl_hdr *)tplg->pos; -- 2.30.2

2 3

[PATCH v6 0/9] ASoC: codecs: add wcd938x support
by Srinivas Kandagatla 20 May '21

20 May '21

This patchset adds support for Qualcomm WCD938X codec. Qualcomm WCD9380/WCD9385 Codec is a standalone Hi-Fi audio codec IC connected over SoundWire. This device has two SoundWire devices, RX and TX respectively supporting 4 x ADCs, ClassH, Ear, Aux PA, 2xHPH, 7 x TX diff inputs, 8 DMICs and MBHC. Eventhough this device has two SoundWire devices, only tx device has access to main codec Control/Status Registers! For codec driver to be functional it would need both tx and rx Soundwire devices to be up and this is taken care by using device component framework and device-links are used to ensure proper pm dependencies. Ex tx does not enter suspend before rx or codec is suspended. This patchset along with other SoundWire patches on the list have been tested on SM8250 MTP device. Thanks, srini Changes since v5: - removed ref in qcom,mbhc-buttons-vthreshold-microvolt bindings to fix dt_bindings_check warning Srinivas Kandagatla (9): ASoC: dt-bindings: wcd938x: add bindings for wcd938x ASoC: codecs: wcd-clsh: add new version support ASoC: codecs: wcd938x: add basic driver ASoC: dt-bindings: wcd938x-sdw: add bindings for wcd938x-sdw ASoC: codecs: wcd938x-sdw: add SoundWire driver ASoC: codecs: wcd938x: add basic controls ASoC: codecs: wcd938x: add playback dapm widgets ASoC: codecs: wcd938x: add capture dapm widgets ASoC: codecs: wcd938x: add audio routing .../bindings/sound/qcom,wcd938x-sdw.yaml | 70 + .../bindings/sound/qcom,wcd938x.yaml | 148 + sound/soc/codecs/Kconfig | 13 + sound/soc/codecs/Makefile | 4 + sound/soc/codecs/wcd-clsh-v2.c | 348 +- sound/soc/codecs/wcd-clsh-v2.h | 16 + sound/soc/codecs/wcd938x-sdw.c | 298 ++ sound/soc/codecs/wcd938x.c | 3753 +++++++++++++++++ sound/soc/codecs/wcd938x.h | 705 ++++ 9 files changed, 5345 insertions(+), 10 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/qcom,wcd938x-sdw.yaml create mode 100644 Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml create mode 100644 sound/soc/codecs/wcd938x-sdw.c create mode 100644 sound/soc/codecs/wcd938x.c create mode 100644 sound/soc/codecs/wcd938x.h -- 2.21.0

2 10

[PATCH v1 0/2] Unify NVIDIA Tegra ASoC machine drivers
by Dmitry Osipenko 19 May '21

19 May '21

During review of the RT5631 machine driver, Jon Hunter suggested that it will be better to squash all the current ASoC machine drivers into a single one. This suggestion is implemented by this patchset. The RT5631 support will come later with the ASUS Transformer changes. Dmitry Osipenko (2): of: base: Export of_device_compatible_match() ASoC: tegra: Unify ASoC machine drivers drivers/of/base.c | 1 + sound/soc/tegra/Kconfig | 12 + sound/soc/tegra/Makefile | 18 +- sound/soc/tegra/tegra_alc5632.c | 259 ---------- sound/soc/tegra/tegra_asoc_machine.c | 737 +++++++++++++++++++++++++++ sound/soc/tegra/tegra_asoc_machine.h | 44 ++ sound/soc/tegra/tegra_max98090.c | 276 ---------- sound/soc/tegra/tegra_rt5640.c | 222 -------- sound/soc/tegra/tegra_rt5677.c | 324 ------------ sound/soc/tegra/tegra_sgtl5000.c | 211 -------- sound/soc/tegra/tegra_wm8753.c | 185 ------- sound/soc/tegra/tegra_wm8903.c | 349 +++---------- sound/soc/tegra/tegra_wm9712.c | 166 ------ sound/soc/tegra/trimslice.c | 172 ------- 14 files changed, 860 insertions(+), 2116 deletions(-) delete mode 100644 sound/soc/tegra/tegra_alc5632.c create mode 100644 sound/soc/tegra/tegra_asoc_machine.c create mode 100644 sound/soc/tegra/tegra_asoc_machine.h delete mode 100644 sound/soc/tegra/tegra_max98090.c delete mode 100644 sound/soc/tegra/tegra_rt5640.c delete mode 100644 sound/soc/tegra/tegra_rt5677.c delete mode 100644 sound/soc/tegra/tegra_sgtl5000.c delete mode 100644 sound/soc/tegra/tegra_wm8753.c delete mode 100644 sound/soc/tegra/tegra_wm9712.c delete mode 100644 sound/soc/tegra/trimslice.c -- 2.30.2

4 13

Intel HDA Driver Issue With PCM RW Interleaved
by re.mcclue 19 May '21

19 May '21

I'm trying to play PCM buffer single threaded without buffer underrun. Program source: https://gist.github.com/takaswie/d8a9553c230971d974a3dfc759b2ff67 (struct snd_pcm_sw_params).start_threshold is altered so as to allow specifying the start of audio frame transmission and prevent underrun issues. In my application, on ioctl(fd, SNDRV_PCM_IOCTL_STATUS, &status), I receive: File descriptor in bad state Output of $(dmesg) is: [ 69.013084] snd_hda_intel 0000:00:1f.3: Too big adjustment 128 What is causing this issue and how can I solve it? Thanks Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 1

[PATCH v3 0/2] ASoC: meson: g12a-toacodec: add support for SM1
by Neil Armstrong 19 May '21

19 May '21

This patchset adds Amlogic SM1 support on the TOACODEC driver, first by switching to regmap fields for some bit fields to avoid code duplication, and then by adding the corresponding bits & struct for the SM1 changed bits. Changes since v2 at [2]: - use raw values instead of defines in REG_FIELD() for g12a_toacodec_match_data Changes since v1 at [1]: - switch to regmap field [1] https://lore.kernel.org/r/20210429170147.3615883-1-narmstrong@baylibre.com [2] https://lore.kernel.org/r/20210505072607.3815442-1-narmstrong@baylibre.com Neil Armstrong (2): ASoC: meson: g12a-toacodec: use regmap fields to prepare SM1 support ASoC: meson: g12a-toacodec: add support for SM1 TOACODEC sound/soc/meson/g12a-toacodec.c | 143 +++++++++++++++++++++++++++----- 1 file changed, 124 insertions(+), 19 deletions(-) -- 2.25.1

2 3