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

no audio when using the dshare plugin with ALSA driver using indirect PCM data transfer
by GitHub issues - edited 17 May '20

17 May '20

alsa-project/alsa-lib issue #51 was edited from bondagit: Hi all, I am currently working on an open source project on GitHub [AES67 Linux daemon implementation](https://github.com/bondagit/aes67-linux-daemon). This project uses the [Merging Technologies ALSA RAVENNA/AES67 Linux Driver](https://bitbucket.org/MergingTechnologies/ravenna-alsa-lkm/src/mast…. This ALSA driver does support the mmap access using the indirect PCM data transfer. The driver is working properly when used directly but not when it's used via the **dshare** plugin. See issue [No sound using dshare in asound.conf](https://github.com/bondagit/aes67-linux-daemon/issues/7) in the AES67 Linux daemon project. For all my tests I used the **Linux Kernel 5.3.0-51** and the **alsa-lib v1.1.9** but I get same results with most recent kernel and with the **alsa-lib** on the master branch. Basically when I playback a sample PCM audio using the ALSA RAVENNA/AES67 HW device directly via mmap I get a proper playout. Ex: `aplay -D hw:1 sample.raw -M` But if I do the same using the dshare plugin I do always get no audio (silence): Ex: `aplay -D mydshare sample.raw -M` After a number of tests trying to compare the behavior of the **alsa-lib** when using the ALSA driver directly (aplay -D hw:1) and when using the plugin (aplay -D mydshare) I realized that in the second case the **SNDRV_PCM_IOCTL_SYNC_PTR ioctl** is never triggered in the audio loop by the **alsa-lib** . (I could easily capture this by using strace). I would expect the `snd_pcm_dshare_mmap_commit() `function of **alsa-lib** to invoke the above ioctl but this is not happening. The result is that in the ALSA driver the **ack()** callback is not called to indicate that the **appl_ptr** is updated and this causes the problem we have. In the Linux kernel when the ioctl SNDRV_PCM_IOCTL_SYNC_PTR is called the following functions are called: `snd_pcm_sync_ptr() -> pcm_lib_apply_appl_ptr() -> substream->ops->ack() ` but as stated above this is happening only if the ALSA driver is used directly (aplay -D hw:1) and not when it's used via the plugin (aplay -D mydshare). I could fix the issue applying the following temporary fix to the `alsa-lib`: ``` diff --git a/src/pcm/pcm_dshare.c b/src/pcm/pcm_dshare.c index f135b5df..1f103414 100644 --- a/src/pcm/pcm_dshare.c +++ b/src/pcm/pcm_dshare.c @@ -562,6 +562,7 @@ static snd_pcm_sframes_t snd_pcm_dshare_mmap_commit(snd_pcm_t *pcm, /* clear timer queue to avoid a bogus return from poll */ if (snd_pcm_mmap_playback_avail(pcm) < pcm->avail_min) snd_pcm_direct_clear_timer_queue(dshare); + dshare->spcm->fast_ops->mmap_commit(dshare->spcm, offset, size); } return size; } ``` The fix basically triggers the call to the `snd_pcm_hw_mmap_commit()` function of the slave pcm of the dshare plugin. This function invokes the ` issue_applptr() ` and then the `sync_ptr1()` that finally calls the SNDRV_PCM_IOCTL_SYNC_PTR ioctl to update the **appl_ptr** in the kernel. After applying this fix I can properly hear the audio. I am available to provide any additional information and to do additional tests. Since I don't have much experience with the `alsa-lib` it can be that the problem is related to some misconfiguration but at present I managed to solve the issue only by applying the above fix. Thanks in advance for your help. Issue URL : https://github.com/alsa-project/alsa-lib/issues/51 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

no audio when using the dshare plugin with a ALSA driver using indirect PCM data transfer
by GitHub issues - edited 17 May '20

17 May '20

alsa-project/alsa-lib issue #51 was edited from bondagit: Hi all, I am currently working on an open source project on GitHub [AES67 Linux daemon implementation](https://github.com/bondagit/aes67-linux-daemon). This project uses the [Merging Technologies ALSA RAVENNA/AES67 Linux Driver](https://bitbucket.org/MergingTechnologies/ravenna-alsa-lkm/src/mast…. This ALSA driver does support the mmap access using the indirect PCM data transfer. The driver is working properly when used directly but not when it's used via the **dshare** plugin. See issue [No sound using dshare in asound.conf](https://github.com/bondagit/aes67-linux-daemon/issues/7) in the AES67 Linux daemon project. For all my tests I used the **Linux Kernel 5.3.0-51** and the **alsa-lib v1.1.9** but I get same results with most recent kernel and with the **alsa-lib** on the master branch. Basically when I playback a sample PCM audio using the ALSA RAVENNA/AES67 HW device directly via mmap I get a proper playout. Ex: `aplay -D hw:1 sample.raw -M` But if I do the same using the dshare plugin I do always get no audio (silence): Ex: `aplay -D mydshare sample.raw -M` After a number of tests trying to compare the behavior of the **alsa-lib** when using the ALSA driver directly (aplay -D hw:1) and when using the plugin (aplay -D mydshare) I realized that in the second case the **SNDRV_PCM_IOCTL_SYNC_PTR ioctl** is never triggered in the audio loop by the **alsa-lib** . (I could easily capture this by using strace). I would expect the `snd_pcm_dshare_mmap_commit() `function of **alsa-lib** to invoke the above ioctl but this is not happening. The result is that in the ALSA driver the **ack()** callback is not called to indicate that the **appl_ptr** is updated and this causes the problem we have. In the Linux kernel when the ioctl SNDRV_PCM_IOCTL_SYNC_PTR is called the following functions are called: `snd_pcm_sync_ptr() -> pcm_lib_apply_appl_ptr() -> substream->ops->ack() ` but as stated above this is happening only if the ALSA driver is used directly (aplay -D hw:1) and not when it's used via the plugin (aplay -D mydshare). I could fix the issue applying the following temporary fix to the `alsa-lib`: ``` diff --git a/src/pcm/pcm_dshare.c b/src/pcm/pcm_dshare.c index f135b5df..1f103414 100644 --- a/src/pcm/pcm_dshare.c +++ b/src/pcm/pcm_dshare.c @@ -562,6 +562,7 @@ static snd_pcm_sframes_t snd_pcm_dshare_mmap_commit(snd_pcm_t *pcm, /* clear timer queue to avoid a bogus return from poll */ if (snd_pcm_mmap_playback_avail(pcm) < pcm->avail_min) snd_pcm_direct_clear_timer_queue(dshare); + dshare->spcm->fast_ops->mmap_commit(dshare->spcm, offset, size); } return size; } ``` The fix basically triggers the call to the `snd_pcm_hw_mmap_commit()` function of the slave pcm of the dshare plugin. This function invokes the ` issue_applptr() ` and then the `sync_ptr1()` that finally calls the SNDRV_PCM_IOCTL_SYNC_PTR ioctl to update the **appl_ptr** in the kernel. After applying this fix I can properly hear the audio. I am available to provide any additional information and to do additional tests. Since I don't have much experience with the `alsa-lib` it can be that the problem is related to some misconfiguration but at present I managed to solve the issue only by applying the above fix. Thanks in advance for your help. Issue URL : https://github.com/alsa-project/alsa-lib/issues/51 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

no audio when using the dshare plugin
by GitHub issues - opened 17 May '20

17 May '20

alsa-project/alsa-lib issue #51 was opened from bondagit: Hi all, I am currently working on an open source project on GitHub [AES67 Linux daemon implementation](https://github.com/bondagit/aes67-linux-daemon). This project uses the [Merging Technologies ALSA RAVENNA/AES67 Linux Driver](https://bitbucket.org/MergingTechnologies/ravenna-alsa-lkm/src/mast…. This ALSA driver does support the mmap access using the indirect PCM data transfer. The driver is working properly when used directly but not when it's used via the **dshare** plugin. See issue [No sound using dshare in asound.conf](https://github.com/bondagit/aes67-linux-daemon/issues/7) in the AES67 Linux daemon project. For all my tests I used the **Linux Kernel 5.3.0-51** and the **alsa-lib v1.1.9** but I get same results with most recent kernel and with the **alsa-lib** on the master branch. Basically when I playback a sample PCM audio using the ALSA RAVENNA/AES67 HW device directly via mmap I get a proper playout. Ex: `aplay -D hw:1 sample.raw -M` But if I do the same using the dshare plugin I do always get no audio (silence): Ex: `aplay -D mydshare sample.raw -M` After a number of tests trying to compare the behavior of the **alsa-lib** when using the ALSA driver directly (aplay -D hw:1) and when using the plugin (aplay -D mydshare) I realized that in the second case the **SNDRV_PCM_IOCTL_SYNC_PTR ioctl** is never triggered in the audio loop by the **alsa-lib** . (I could easily capture this by using strace). I would expect the `snd_pcm_dshare_mmap_commit() `function of **alsa-lib** to invoke the above ioctl but this is not happening. The result is that in the ALSA driver the **ack()** callback is not called to indicate that the **appl_ptr** is updated and this causes the problem we have. In the Linux kernel when the ioctl SNDRV_PCM_IOCTL_SYNC_PTR is called the following functions are called: `snd_pcm_sync_ptr() -> pcm_lib_apply_appl_ptr() -> substream->ops->ack() ` but as stated above this is happening only if the ALSA driver is used directly (aplay -D hw:1) and not when it's used via the plugin (aplay -D mydshare). I could fix the issue applying the following temporary fix to the `alsa-lib`: ``` diff --git a/src/pcm/pcm_dshare.c b/src/pcm/pcm_dshare.c index f135b5df..1f103414 100644 --- a/src/pcm/pcm_dshare.c +++ b/src/pcm/pcm_dshare.c @@ -562,6 +562,7 @@ static snd_pcm_sframes_t snd_pcm_dshare_mmap_commit(snd_pcm_t *pcm, /* clear timer queue to avoid a bogus return from poll */ if (snd_pcm_mmap_playback_avail(pcm) < pcm->avail_min) snd_pcm_direct_clear_timer_queue(dshare); + dshare->spcm->fast_ops->mmap_commit(dshare->spcm, offset, size); } return size; } ``` The fix basically triggers the call to the `snd_pcm_hw_mmap_commit()` function of the slave pcm of the dshare plugin. This function invokes the ` issue_applptr() ` and then the `sync_ptr1()` that finally calls the SNDRV_PCM_IOCTL_SYNC_PTR ioctl to update the **appl_ptr** in the kernel. After applying this fix I can properly hear the audio. I am available to provide any additional information and to do additional tests. Since I don't have much experience with the `alsa-lib` it can be that the problem is related to some misconfiguration but at present I managed to solve the issue only by applying the above fix. Thanks in advance for your help. Issue URL : https://github.com/alsa-project/alsa-lib/issues/51 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

ucm: initialize mgr->once_list
by GitHub pull_request - opened 16 May '20

16 May '20

alsa-project/alsa-lib pull request #50 was opened from asavah: Initiliaze mgr->once_list otherwise eg `alsactl restore 0` will segfault in https://github.com/alsa-project/alsa-lib/blob/master/src/ucm/utils.c#L570 in case that `/var/lib/alsa/alsa.state` is not present. Request URL : https://github.com/alsa-project/alsa-lib/pull/50 Patch URL : https://github.com/alsa-project/alsa-lib/pull/50.patch Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH 0/2] ALSA: hda: Cleanup helpers
by Takashi Iwai 16 May '20

16 May '20

Some helper functions are used only locally or not used, here just a simple cleanup. Takashi === Takashi Iwai (2): ALSA: hda: Drop unused snd_hda_queue_unsol_event() ALSA: hda: Unexport some local helper functions include/sound/hda_codec.h | 7 ------- include/sound/hdaudio.h | 3 --- sound/hda/hdac_bus.c | 2 -- sound/hda/hdac_controller.c | 1 + sound/hda/local.h | 3 +++ 5 files changed, 4 insertions(+), 12 deletions(-) -- 2.16.4

1 2

[PATCH] ALSA: hda: Fix potential race in unsol event handler
by Takashi Iwai 16 May '20

16 May '20

The unsol event handling code has a loop retrieving the read/write indices and the arrays without locking while the append to the array may happen concurrently. This may lead to some inconsistency. Although there hasn't been any proof of this bad results, it's still safer to protect the racy accesses. This patch adds the spinlock protection around the unsol handling loop for addressing it. Here we take bus->reg_lock as the writer side snd_hdac_bus_queue_event() is also protected by that lock. Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/hda/hdac_bus.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/sound/hda/hdac_bus.c b/sound/hda/hdac_bus.c index 26b391be3656..09ddab5f5cae 100644 --- a/sound/hda/hdac_bus.c +++ b/sound/hda/hdac_bus.c @@ -160,6 +160,7 @@ static void snd_hdac_bus_process_unsol_events(struct work_struct *work) struct hdac_driver *drv; unsigned int rp, caddr, res; + spin_lock_irq(&bus->reg_lock); while (bus->unsol_rp != bus->unsol_wp) { rp = (bus->unsol_rp + 1) % HDA_UNSOL_QUEUE_SIZE; bus->unsol_rp = rp; @@ -171,10 +172,13 @@ static void snd_hdac_bus_process_unsol_events(struct work_struct *work) codec = bus->caddr_tbl[caddr & 0x0f]; if (!codec || !codec->dev.driver) continue; + spin_unlock_irq(&bus->reg_lock); drv = drv_to_hdac_driver(codec->dev.driver); if (drv->unsol_event) drv->unsol_event(codec, res); + spin_lock_irq(&bus->reg_lock); } + spin_unlock_irq(&bus->reg_lock); } /** -- 2.25.0

1 0

Alsa doesn't respect XDG Base Directory standard?
by GitHub issues - opened 16 May '20

16 May '20

alsa-project/alsa-lib issue #49 was opened from luxintra: My .config is set to $XDG_CONFIG_HOME and moving asoundrc to $XDG_CONFIG_HOME/alsa ...does not work for me. Issue URL : https://github.com/alsa-project/alsa-lib/issues/49 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH] ALSA: fixing upper volume limit for RME Babyface Pro routing crosspoints.
by Thomas Ebeling 15 May '20

15 May '20

In my initial patch, these were set too low. Signed-off-by: Thomas Ebeling <penguins(a)bollie.de> --- sound/usb/mixer_quirks.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/usb/mixer_quirks.c b/sound/usb/mixer_quirks.c index bdff8674942e..aad2683ff793 100644 --- a/sound/usb/mixer_quirks.c +++ b/sound/usb/mixer_quirks.c @@ -2191,7 +2191,7 @@ static int snd_rme_controls_create(struct usb_mixer_interface *mixer) * These devices exposes a couple of DSP functions via request to EP0. * Switches are available via control registers, while routing is controlled * by controlling the volume on each possible crossing point. - * Volume control is linear, from -inf (dec. 0) to +6dB (dec. 46341) with + * Volume control is linear, from -inf (dec. 0) to +6dB (dec. 65536) with * 0dB being at dec. 32768. */ enum { @@ -2220,7 +2220,7 @@ enum { #define SND_BBFPRO_MIXER_VAL_MASK 0x3ffff #define SND_BBFPRO_MIXER_VAL_SHIFT 9 #define SND_BBFPRO_MIXER_VAL_MIN 0 // -inf -#define SND_BBFPRO_MIXER_VAL_MAX 46341 // +6dB +#define SND_BBFPRO_MIXER_VAL_MAX 65536 // +6dB #define SND_BBFPRO_USBREQ_CTL_REG1 0x10 #define SND_BBFPRO_USBREQ_CTL_REG2 0x17 -- 2.26.2

2 1

core: snd_card_disconnect/snd_card_free: hang when card unregistered
by Dexter Travis 15 May '20

15 May '20

In my system during certain power events the power rail for the TLV320AIC3120 goes away and may come back. To accommodate this I have added a call to snd_soc_unregister_card as soon as I notice via GPIO that this power has been removed. I then call snd_soc_register_card to re-install the sound card after power is restored. If no sound is playing when the asynchronous power removal occurs this works fine. If a sound is playing one of two things will occur. In the first case the sound driver comes back and sound is restored when power is restored. In the second case my deferred work function which calls the snd_soc_unregister_card function gets hung and does not return. I have traced the difference to the wait_for_completion call in snd_card_free. if snd_card_disconnect adds files to shutdown_files list then wait_for_completion will hang forever. Any suggestions on how to further debug this? How to force the immediate unregister of the card even if a sound is playing? Thank you, Dexter Travis

2 3

[PATCH v2] ASoC: cros_ec_codec: switch to library API for SHA-256
by Ard Biesheuvel 15 May '20

15 May '20

The CrOS EC codec driver uses SHA-256 explicitly, and not in a performance critical manner, so there is really no point in using the SHASH crypto API here. Let's switch to the library API instead. Cc: Cheng-Yi Chiang <cychiang(a)chromium.org> Cc: Enric Balletbo i Serra <enric.balletbo(a)collabora.com> Cc: Guenter Roeck <groeck(a)chromium.org> Cc: Benson Leung <bleung(a)chromium.org> Cc: Liam Girdwood <lgirdwood(a)gmail.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Eric Biggers <ebiggers(a)kernel.org> Cc: Herbert Xu <herbert(a)gondor.apana.org.au> Cc: Tzung-Bi Shih <tzungbi(a)google.com> Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> --- v2: - rebase onto sound/for-5.8 - drop pointless memzero_explicit() - drop include of crypto/hash.h sound/soc/codecs/Kconfig | 3 +-- sound/soc/codecs/cros_ec_codec.c | 23 ++++---------------- 2 files changed, 5 insertions(+), 21 deletions(-) diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 44b8c4cde4f3..2d4f1b4bc011 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -538,8 +538,7 @@ config SND_SOC_CQ0093VC config SND_SOC_CROS_EC_CODEC tristate "codec driver for ChromeOS EC" depends on CROS_EC - select CRYPTO - select CRYPTO_SHA256 + select CRYPTO_LIB_SHA256 help If you say yes here you will get support for the ChromeOS Embedded Controller's Audio Codec. diff --git a/sound/soc/codecs/cros_ec_codec.c b/sound/soc/codecs/cros_ec_codec.c index 1948bc6971f6..8d45c628e988 100644 --- a/sound/soc/codecs/cros_ec_codec.c +++ b/sound/soc/codecs/cros_ec_codec.c @@ -8,7 +8,6 @@ * EC for audio function. */ -#include <crypto/hash.h> #include <crypto/sha.h> #include <linux/acpi.h> #include <linux/delay.h> @@ -107,25 +106,11 @@ static int send_ec_host_command(struct cros_ec_device *ec_dev, uint32_t cmd, static int calculate_sha256(struct cros_ec_codec_priv *priv, uint8_t *buf, uint32_t size, uint8_t *digest) { - struct crypto_shash *tfm; - struct shash_desc *desc; + struct sha256_state sctx; - tfm = crypto_alloc_shash("sha256", CRYPTO_ALG_TYPE_SHASH, 0); - if (IS_ERR(tfm)) { - dev_err(priv->dev, "can't alloc shash\n"); - return PTR_ERR(tfm); - } - desc = kmalloc(sizeof(*desc) + crypto_shash_descsize(tfm), GFP_KERNEL); - if (!desc) { - crypto_free_shash(tfm); - return -ENOMEM; - } - desc->tfm = tfm; - crypto_shash_digest(desc, buf, size, digest); - shash_desc_zero(desc); - - kfree(desc); - crypto_free_shash(tfm); + sha256_init(&sctx); + sha256_update(&sctx, buf, size); + sha256_final(&sctx, digest); #ifdef DEBUG { -- 2.17.1

3 2