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

[PATCH 0/2] ALSA: trivial corrections
by Pierre-Louis Bossart 13 Aug '21

13 Aug '21

One typo and one deprecated function to be replaced. Pierre-Louis Bossart (2): ALSA: core: control_led: use strscpy instead of strlcpy ALSA: hda_audio_ext: fix kernel-doc include/sound/hdaudio_ext.h | 2 +- sound/core/control_led.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.25.1

2 3

[PATCH RFC v2 0/4] ALSA: Support for non-coherent and non-contiguous page allocation
by Takashi Iwai 13 Aug '21

13 Aug '21

Hi, this is a revised patchset to add the support for PCM buffers with non-coherent and non-contiguous pages, typically useful for non-x86 architectures. The first patch improves the SG-buffer handling, then add a new PCM info flag that disables the control and status mmap, and implements two new buffer types, SNDRV_DMA_TYPE_NONCONTIG and SNDRV_DMA_TYPE_NONCOHERENT. The former is the SG-buffer and the latter is the continuous page allocation, corresponding to SNDRV_DMA_TYPE_DEV_SG and SNDRV_DMA_TYPE_DEV on x86. Unlike other page types, those are directional (that need the DMA direction at allocation time) and require the explicit sync of buffers around the data transfer (flushing, invalidating). The sync is implemented inside ALSA PCM core and automatically applied at updating the applptr and hwsync via SYNC_PTR ioctl, which should be issued during mmap operation, so it should work transparently as long as applications are running with alsa-lib. For tinyALSA, we might need to revisit the implementation. This is currently an RFC -- more exactly, CALL FOR TESTERS, as I have no Arm machine with the sound device for now. The needed change for an existing driver is simple: * Replace the buffer type from SNDRV_DMA_TYPE_DEV to SNDRV_DMA_TYPE_NONCOHERENT (or from SNDRV_DMA_TYPE_DEV_SG to SNDRV_DMA_TYPE_NONCONTIG), which is set up typically in snd_pcm_set_managed_buffer*() call. * Add SNDRV_PCM_INFO_EXPLICIT_SYNC flag to the PCM runtime hardware.info field It'd be greatly appreciated if anyone can test and try the changes, and help debugging. Again, the code is faily untested. The latest code is found in topic/memalloc-noncontig branch of my sound git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git The patch set is based on for-next branch, i.e. changes for 5.15 are included. thanks, Takashi === v1: https://lore.kernel.org/r/20210810122200.971-1-tiwai@suse.de v1->v2: * Drop the optimization patch for embedding ops that turned out to be negligible but causing a trouble with the existing sgbuf. * Minor code refactoring === Takashi Iwai (4): ALSA: memalloc: Count continuous pages in vmalloc buffer handler ALSA: pcm: Add SNDRV_PCM_INFO_EXPLICIT_SYNC flag ALSA: memalloc: Support for non-contiguous page allocation ALSA: memalloc: Support for non-coherent page allocation include/sound/memalloc.h | 46 +++++++++- include/uapi/sound/asound.h | 1 + sound/core/memalloc.c | 172 ++++++++++++++++++++++++++++++++---- sound/core/memalloc_local.h | 1 + sound/core/pcm_lib.c | 3 + sound/core/pcm_local.h | 7 ++ sound/core/pcm_memory.c | 13 ++- sound/core/pcm_native.c | 15 ++++ 8 files changed, 236 insertions(+), 22 deletions(-) -- 2.26.2

2 6

ASoC: question about asoc and external modem used with mux
by Dev Null 12 Aug '21

12 Aug '21

Hi, On the motorola droid 4 (xt894 rch/arm/boot/dts/omap4-droid4-xt894.dts) the cpcap asoc codec is used for sound (sound/soc/codecs/cpcap.c). The codec contains a hifi and voice DAI and mixer controlls to connect the various outputs (headphones, internal speaker, earpiece etc) to these dai. The hardware setup looks like this https://lkml.org/lkml/2018/3/27/1225 with the cpcap chip acting as a mux for various other devices on the pcb. The modem is one of these devices. The problem is that the kernel has really no way of knowing if the modem is outputing anything or not and thus if the mixer is setup sutch that the modem is driving some output though dapm route (eg the earpiece), the entire dapm route chain will remain off and inactive causeing the kernel to disable the Earpiece PGA. Thus no output makes it out of the device and the voice call fails unless one messes with the registers to enable Earpiece PGA by hand. Now i know of various ways to hack this problem away and have been looking at the asoc/ alsa documentation for some time now but i really cant seam to figure out how to solve this problem correctly. Really i would need a way to pin the voice dai to be considerd allways active by the kernel so that all downsteam devices get truned on when the mixer is setup sutch that they are conected in a route. Or give userspace a mixer switch or other mechanisum to tell the kernel that the modem is currently actively playing sound. any help that can be given in this problem would me mutch appreciated. -- Dev Null <devnull(a)uvos.xyz>

1 0

pulseaudio: a52 sink doesn't stream audio from bluez source
by GitHub issues - opened 12 Aug '21

12 Aug '21

alsa-project/alsa-plugins issue #32 was opened from quequotion: Sorry to beat a dead horse, and double if this is in fact a pulseaudio issue. I recently configured bluez and pulseaudio to receive streams from devices over bluetooth (eg, to play audio from a phone over the PC's speaker system). This works when the PC's sound card is set to profiles *other than* the A52 plugin (ie, pulseaudio's provided digital stereo output and also the [DTS alsa plugin](https://github.com/darealshinji/dcaenc)). Only when set to use the AC3 output profile, audio from the bluez source is not produced. pavucontrol shows the bluez source is producing sound (the level bounces appropriately), but no audio comes out of the sink (no level bounce in pavucontrol either). Any ideas? Issue URL : https://github.com/alsa-project/alsa-plugins/issues/32 Repository URL: https://github.com/alsa-project/alsa-plugins

1 0

[PATCH 1/2] Revert "ASoC: rt5682: Adjust headset volume button threshold"
by derek.fang＠realtek.com 12 Aug '21

12 Aug '21

From: Derek Fang <derek.fang(a)realtek.com> This reverts commit 6d20bf7c020f417fdef1810a22da17c126603472. Since it may risk affecting other headset Vol- button. Signed-off-by: Derek Fang <derek.fang(a)realtek.com> diff --git a/sound/soc/codecs/rt5682.c b/sound/soc/codecs/rt5682.c index 7dc01ae6bb66..fcf442b8a732 100644 --- a/sound/soc/codecs/rt5682.c +++ b/sound/soc/codecs/rt5682.c @@ -44,7 +44,6 @@ static const struct reg_sequence patch_list[] = { {RT5682_I2C_CTRL, 0x000f}, {RT5682_PLL2_INTERNAL, 0x8266}, {RT5682_SAR_IL_CMD_3, 0x8365}, - {RT5682_SAR_IL_CMD_6, 0x0180}, }; void rt5682_apply_patch_list(struct rt5682_priv *rt5682, struct device *dev) -- 2.17.1

2 4

[PATCH v2] ASoC: rt5682: Properly turn off regulators if wrong device ID
by Douglas Anderson 12 Aug '21

12 Aug '21

When I booted up on a board that had a slightly different codec stuffed on it, I got this message at bootup: rt5682 9-001a: Device with ID register 6749 is not rt5682 That's normal/expected, but what wasn't normal was the splat that I got after: WARNING: CPU: 7 PID: 176 at drivers/regulator/core.c:2151 _regulator_put+0x150/0x158 pc : _regulator_put+0x150/0x158 ... Call trace: _regulator_put+0x150/0x158 regulator_bulk_free+0x48/0x70 devm_regulator_bulk_release+0x20/0x2c release_nodes+0x1cc/0x244 devres_release_all+0x44/0x60 really_probe+0x17c/0x378 ... This is because the error paths don't turn off the regulator. Let's fix that. Fixes: 0ddce71c21f0 ("ASoC: rt5682: add rt5682 codec driver") Fixes: 87b42abae99d ("ASoC: rt5682: Implement remove callback") Signed-off-by: Douglas Anderson <dianders(a)chromium.org> Reviewed-by: Stephen Boyd <swboyd(a)chromium.org> --- Changes in v2: - Add a blank line. sound/soc/codecs/rt5682-i2c.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/rt5682-i2c.c b/sound/soc/codecs/rt5682-i2c.c index 4a56a52adab5..e559b965a0a6 100644 --- a/sound/soc/codecs/rt5682-i2c.c +++ b/sound/soc/codecs/rt5682-i2c.c @@ -117,6 +117,13 @@ static struct snd_soc_dai_driver rt5682_dai[] = { }, }; +static void rt5682_i2c_disable_regulators(void *data) +{ + struct rt5682_priv *rt5682 = data; + + regulator_bulk_disable(ARRAY_SIZE(rt5682->supplies), rt5682->supplies); +} + static int rt5682_i2c_probe(struct i2c_client *i2c, const struct i2c_device_id *id) { @@ -157,6 +164,11 @@ static int rt5682_i2c_probe(struct i2c_client *i2c, return ret; } + ret = devm_add_action_or_reset(&i2c->dev, rt5682_i2c_disable_regulators, + rt5682); + if (ret) + return ret; + ret = regulator_bulk_enable(ARRAY_SIZE(rt5682->supplies), rt5682->supplies); if (ret) { @@ -285,7 +297,6 @@ static int rt5682_i2c_remove(struct i2c_client *client) struct rt5682_priv *rt5682 = i2c_get_clientdata(client); rt5682_i2c_shutdown(client); - regulator_bulk_disable(ARRAY_SIZE(rt5682->supplies), rt5682->supplies); return 0; } -- 2.32.0.605.g8dce9f2422-goog

2 1

[PATCH] ASoC: rt5682: Properly turn off regulators if wrong device ID
by Douglas Anderson 12 Aug '21

12 Aug '21

When I booted up on a board that had a slightly different codec stuffed on it, I got this message at bootup: rt5682 9-001a: Device with ID register 6749 is not rt5682 That's normal/expected, but what wasn't normal was the splat that I got after: WARNING: CPU: 7 PID: 176 at drivers/regulator/core.c:2151 _regulator_put+0x150/0x158 pc : _regulator_put+0x150/0x158 ... Call trace: _regulator_put+0x150/0x158 regulator_bulk_free+0x48/0x70 devm_regulator_bulk_release+0x20/0x2c release_nodes+0x1cc/0x244 devres_release_all+0x44/0x60 really_probe+0x17c/0x378 ... This is because the error paths don't turn off the regulator. Let's fix that. Fixes: 0ddce71c21f0 ("ASoC: rt5682: add rt5682 codec driver") Fixes: 87b42abae99d ("ASoC: rt5682: Implement remove callback") Signed-off-by: Douglas Anderson <dianders(a)chromium.org> --- sound/soc/codecs/rt5682-i2c.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/rt5682-i2c.c b/sound/soc/codecs/rt5682-i2c.c index 4a56a52adab5..1cc07812b5ac 100644 --- a/sound/soc/codecs/rt5682-i2c.c +++ b/sound/soc/codecs/rt5682-i2c.c @@ -117,6 +117,13 @@ static struct snd_soc_dai_driver rt5682_dai[] = { }, }; +static void rt5682_i2c_disable_regulators(void *data) +{ + struct rt5682_priv *rt5682 = data; + + regulator_bulk_disable(ARRAY_SIZE(rt5682->supplies), rt5682->supplies); +} + static int rt5682_i2c_probe(struct i2c_client *i2c, const struct i2c_device_id *id) { @@ -156,6 +163,10 @@ static int rt5682_i2c_probe(struct i2c_client *i2c, dev_err(&i2c->dev, "Failed to request supplies: %d\n", ret); return ret; } + ret = devm_add_action_or_reset(&i2c->dev, rt5682_i2c_disable_regulators, + rt5682); + if (ret) + return ret; ret = regulator_bulk_enable(ARRAY_SIZE(rt5682->supplies), rt5682->supplies); @@ -285,7 +296,6 @@ static int rt5682_i2c_remove(struct i2c_client *client) struct rt5682_priv *rt5682 = i2c_get_clientdata(client); rt5682_i2c_shutdown(client); - regulator_bulk_disable(ARRAY_SIZE(rt5682->supplies), rt5682->supplies); return 0; } -- 2.32.0.605.g8dce9f2422-goog

4 5

waiting for a connection
by folkert 12 Aug '21

12 Aug '21

Hi, When I create an ALSA MIDI port, is it possible (how?) to wait for someone to connect to it/map it to an other port? This would allow me to only allocate extra resources when needed (in my case: connect to ipmidi-peer (in unicast mode)). regards

2 1

[PATCH v4 00/27] ALSA: hda/cirrus: Split generic cirrus HDA codecs and CS8490 bridge into separate modules.
by Vitaly Rodionov 12 Aug '21

12 Aug '21

This series of patches splits generic cirrus HDA codecs and CS8490 bridge into separate modules, adds support for multiple companion codecs connected to CS8409, and also adds support for new DELL HW platform. CS8409 part is not really a HDA codec, it is a HDA bridge where companion codecs (up to 16) can be attached. With growing number of supported configurations and platforms, patch_cirrus is getting less and less transparent and maintainable. So, the logical step is to separate generic Cirrus HDA codecs support and Cirrus HDA bridge support. Lots of improvements to existing functionality, code clean-up and refactoring, remove duplicated/redundant code, improve I2C functions etc. Add support for new DELL HW platform with 2 CS42L42 codecs for front and rear jacks. Lucas Tanure (12): ALSA: hda/cirrus: Move CS8409 HDA bridge to separate module ALSA: hda/cs8409: Move arrays of configuration to a new file ALSA: hda/cs8409: Disable unsolicited response for the first boot ALSA: hda/cs8409: Prevent I2C access during suspend time ALSA: hda/cs8409: Generalize volume controls ALSA: hda/cs8409: Dont disable I2C clock between consecutive accesses ALSA: hda/cs8409: Avoid setting the same I2C address for every access ALSA: hda/cs8409: Avoid re-setting the same page as the last access ALSA: hda/cs8409: Support i2c bulk read/write functions ALSA: hda/cs8409: Separate CS8409, CS42L42 and project functions ALSA: hda/cs8409: Move codec properties to its own struct ALSA: hda/cs8409: Add support for dolphin Stefan Binding (15): ALSA: hda/cs8409: Use enums for register names and coefficients ALSA: hda/cs8409: Mask all CS42L42 interrupts on initialization ALSA: hda/cs8409: Reduce HS pops/clicks for Cyborg ALSA: hda/cs8409: Disable unnecessary Ring Sense for Cyborg/Warlock/Bullseye ALSA: hda/cs8409: Disable unsolicited responses during suspend ALSA: hda/cs8409: Mask CS42L42 wake events ALSA: hda/cs8409: Simplify CS42L42 jack detect. ALSA: hda/cs8409: Support multiple sub_codecs for Suspend/Resume/Unsol events ALSA: hda/cs8409: Add Support to disable jack type detection for CS42L42 ALSA: hda/cs8409: Enable Full Scale Volume for Line Out Codec on Dolphin ALSA: hda/cs8409: Set fixed sample rate of 48kHz for CS42L42 ALSA: hda/cs8409: Use timeout rather than retries for I2C transaction waits ALSA: hda/cs8409: Remove unnecessary delays ALSA: hda/cs8409: Follow correct CS42L42 power down sequence for suspend ALSA: hda/cs8409: Unmute/Mute codec when stream starts/stops sound/pci/hda/Kconfig | 10 + sound/pci/hda/Makefile | 2 + sound/pci/hda/patch_cirrus.c | 1074 ---------------------- sound/pci/hda/patch_cs8409-tables.c | 560 ++++++++++++ sound/pci/hda/patch_cs8409.c | 1273 +++++++++++++++++++++++++++ sound/pci/hda/patch_cs8409.h | 369 ++++++++ 6 files changed, 2214 insertions(+), 1074 deletions(-) create mode 100644 sound/pci/hda/patch_cs8409-tables.c create mode 100644 sound/pci/hda/patch_cs8409.c create mode 100644 sound/pci/hda/patch_cs8409.h -- 2.25.1

2 28

[PATCH] ALSA: oxfw: fix functioal regression for silence in Apogee Duet FireWire
by Takashi Sakamoto 12 Aug '21

12 Aug '21

OXFW 971 has no function to use the value in syt field of received isochronous packet for playback timing generation. In kernel prepatch for v5.14, ALSA OXFW driver got change to send NO_INFO value in the field instead of actual timing value. The change brings Apogee Duet FireWire to generate no playback sound, while output meter moves. As long as I investigate, _any_ value in the syt field takes the device to generate sound. It's reasonable to think that the device just ignores data blocks in packet with NO_INFO value in its syt field for audio data processing. This commit adds a new flag for the quirk to fix regression. Fixes: 029ffc429440 ("ALSA: oxfw: perform sequence replay for media clock recovery") Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/oxfw/oxfw-stream.c | 9 ++++++++- sound/firewire/oxfw/oxfw.c | 6 ++++-- sound/firewire/oxfw/oxfw.h | 5 +++++ 3 files changed, 17 insertions(+), 3 deletions(-) diff --git a/sound/firewire/oxfw/oxfw-stream.c b/sound/firewire/oxfw/oxfw-stream.c index 0ef242fdd3bc..fff18b5d4e05 100644 --- a/sound/firewire/oxfw/oxfw-stream.c +++ b/sound/firewire/oxfw/oxfw-stream.c @@ -153,7 +153,7 @@ static int init_stream(struct snd_oxfw *oxfw, struct amdtp_stream *stream) struct cmp_connection *conn; enum cmp_direction c_dir; enum amdtp_stream_direction s_dir; - unsigned int flags = CIP_UNAWARE_SYT; + unsigned int flags = 0; int err; if (!(oxfw->quirks & SND_OXFW_QUIRK_BLOCKING_TRANSMISSION)) @@ -161,6 +161,13 @@ static int init_stream(struct snd_oxfw *oxfw, struct amdtp_stream *stream) else flags |= CIP_BLOCKING; + // OXFW 970/971 has no function to generate playback timing according to the sequence + // of value in syt field, thus the packet should include NO_INFO value in the field. + // However, some models just ignore data blocks in packet with NO_INFO for audio data + // processing. + if (!(oxfw->quirks & SND_OXFW_QUIRK_IGNORE_NO_INFO_PACKET)) + flags |= CIP_UNAWARE_SYT; + if (stream == &oxfw->tx_stream) { conn = &oxfw->out_conn; c_dir = CMP_OUTPUT; diff --git a/sound/firewire/oxfw/oxfw.c b/sound/firewire/oxfw/oxfw.c index 84971d78d152..cb5b5e3a481b 100644 --- a/sound/firewire/oxfw/oxfw.c +++ b/sound/firewire/oxfw/oxfw.c @@ -159,8 +159,10 @@ static int detect_quirks(struct snd_oxfw *oxfw, const struct ieee1394_device_id return snd_oxfw_scs1x_add(oxfw); } - if (entry->vendor_id == OUI_APOGEE && entry->model_id == MODEL_DUET_FW) - oxfw->quirks |= SND_OXFW_QUIRK_BLOCKING_TRANSMISSION; + if (entry->vendor_id == OUI_APOGEE && entry->model_id == MODEL_DUET_FW) { + oxfw->quirks |= SND_OXFW_QUIRK_BLOCKING_TRANSMISSION | + SND_OXFW_QUIRK_IGNORE_NO_INFO_PACKET; + } /* * TASCAM FireOne has physical control and requires a pair of additional diff --git a/sound/firewire/oxfw/oxfw.h b/sound/firewire/oxfw/oxfw.h index ee47abcb0c90..c13034f6c2ca 100644 --- a/sound/firewire/oxfw/oxfw.h +++ b/sound/firewire/oxfw/oxfw.h @@ -42,6 +42,11 @@ enum snd_oxfw_quirk { SND_OXFW_QUIRK_BLOCKING_TRANSMISSION = 0x04, // Stanton SCS1.d and SCS1.m support unique transaction. SND_OXFW_QUIRK_SCS_TRANSACTION = 0x08, + // Apogee Duet FireWire ignores data blocks in packet with NO_INFO for audio data + // processing, while output level meter moves. Any value in syt field of packet takes + // the device to process audio data even if the value is invalid in a point of + // IEC 61883-1/6. + SND_OXFW_QUIRK_IGNORE_NO_INFO_PACKET = 0x10, }; /* This is an arbitrary number for convinience. */ -- 2.30.2

2 1