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

Release change info in release [atom feed] messages?
by GitHub issues - opened 15 Oct '20

15 Oct '20

alsa-project/alsa-lib issue #86 was opened from mxmilkiib: I'm currently working on an software update aggregation system - https://libreav.org/updates - and I'd like to add ALSA itself, but I don't think there is a feed for this other than https://github.com/alsa-project/alsa-lib/releases.atom. However, the releases.atom entries do not contain the Changes summary that is used on [the wiki](https://www.alsa-project.org/wiki/Changes_v1.2.3.1_v1.2.3.2). Might it be possible for the release messages to contain those texts? Issue URL : https://github.com/alsa-project/alsa-lib/issues/86 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

pcm_meter.c issue at s16_update
by Go Peppy 15 Oct '20

15 Oct '20

Hi, It would be great to have a fix/patch from Pavel in the main codebase. I've tested his fix and it worked fine. Just to remind what the issue is - while switching from one web radio station to another there is a high CPU usage for about 20 seconds. Because of that high CPU consumption almost all other processes are blocked. The fix from Pavel helps to avoid this situation. Without the ALSA patch I need to make a custom ALSA build every time I release my software. This is very annoying. Thanks in advance!

3 3

[PATCH] ASoC: Intel: atom: Remove duplicate kconfigs
by Cezary Rojewski 14 Oct '20

14 Oct '20

SND_SST_IPC and its _PCI and _ACPI variants all target sound/soc/intel/atom solution alone. SND_SST_IPC is the core component, required for PCI and ACPI based atom platforms both. _PCI and _ACPI target Merrifield/Edison and Baytrial/Cherrytrail platforms respectively. On top of that, there is an equivalent set of configs targeting the same solution: - SND_SST_ATOM_HIFI2_PLATFORM (core) - SND_SST_ATOM_HIFI2_PLATFORM_PCI - SND_SST_ATOM_HIFI2_PLATFORM_ACPI As both sets do the same job - allow for granular platform selection - remove the duplicate set and rely on SND_SST_ATOM_HIFI2_PLATOFRM_XXX configs alone. Signed-off-by: Cezary Rojewski <cezary.rojewski(a)intel.com> --- sound/soc/intel/Kconfig | 18 ------------------ sound/soc/intel/atom/Makefile | 2 +- sound/soc/intel/atom/sst/Makefile | 6 +++--- 3 files changed, 4 insertions(+), 22 deletions(-) diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig index d5bae5d1ab6f..a5b446d5af19 100644 --- a/sound/soc/intel/Kconfig +++ b/sound/soc/intel/Kconfig @@ -15,22 +15,6 @@ config SND_SOC_INTEL_SST_TOPLEVEL if SND_SOC_INTEL_SST_TOPLEVEL -config SND_SST_IPC - tristate - # This option controls the IPC core for HiFi2 platforms - -config SND_SST_IPC_PCI - tristate - select SND_SST_IPC - # This option controls the PCI-based IPC for HiFi2 platforms - # (Medfield, Merrifield). - -config SND_SST_IPC_ACPI - tristate - select SND_SST_IPC - # This option controls the ACPI-based IPC for HiFi2 platforms - # (Baytrail, Cherrytrail) - config SND_SOC_INTEL_SST tristate @@ -57,7 +41,6 @@ config SND_SST_ATOM_HIFI2_PLATFORM config SND_SST_ATOM_HIFI2_PLATFORM_PCI tristate "PCI HiFi2 (Merrifield) Platforms" depends on X86 && PCI - select SND_SST_IPC_PCI select SND_SST_ATOM_HIFI2_PLATFORM help If you have a Intel Merrifield/Edison platform, then @@ -70,7 +53,6 @@ config SND_SST_ATOM_HIFI2_PLATFORM_ACPI tristate "ACPI HiFi2 (Baytrail, Cherrytrail) Platforms" default ACPI depends on X86 && ACPI && PCI - select SND_SST_IPC_ACPI select SND_SST_ATOM_HIFI2_PLATFORM select SND_SOC_ACPI_INTEL_MATCH select IOSF_MBI diff --git a/sound/soc/intel/atom/Makefile b/sound/soc/intel/atom/Makefile index a9326d5ec44c..c66f03f5d8d6 100644 --- a/sound/soc/intel/atom/Makefile +++ b/sound/soc/intel/atom/Makefile @@ -6,4 +6,4 @@ snd-soc-sst-atom-hifi2-platform-objs := sst-mfld-platform-pcm.o \ obj-$(CONFIG_SND_SST_ATOM_HIFI2_PLATFORM) += snd-soc-sst-atom-hifi2-platform.o # DSP driver -obj-$(CONFIG_SND_SST_IPC) += sst/ +obj-$(CONFIG_SND_SST_ATOM_HIFI2_PLATFORM) += sst/ diff --git a/sound/soc/intel/atom/sst/Makefile b/sound/soc/intel/atom/sst/Makefile index f17c905df3e2..5761d30a5f9d 100644 --- a/sound/soc/intel/atom/sst/Makefile +++ b/sound/soc/intel/atom/sst/Makefile @@ -3,6 +3,6 @@ snd-intel-sst-core-objs := sst.o sst_ipc.o sst_stream.o sst_drv_interface.o sst_ snd-intel-sst-pci-objs += sst_pci.o snd-intel-sst-acpi-objs += sst_acpi.o -obj-$(CONFIG_SND_SST_IPC) += snd-intel-sst-core.o -obj-$(CONFIG_SND_SST_IPC_PCI) += snd-intel-sst-pci.o -obj-$(CONFIG_SND_SST_IPC_ACPI) += snd-intel-sst-acpi.o +obj-$(CONFIG_SND_SST_ATOM_HIFI2_PLATFORM) += snd-intel-sst-core.o +obj-$(CONFIG_SND_SST_ATOM_HIFI2_PLATFORM_PCI) += snd-intel-sst-pci.o +obj-$(CONFIG_SND_SST_ATOM_HIFI2_PLATFORM_ACPI) += snd-intel-sst-acpi.o -- 2.17.1

3 2

[PATCH 1/2] ASoC: Intel: catpt: Wake up device before configuring SSP port
by Cezary Rojewski 14 Oct '20

14 Oct '20

catpt_dai_pcm_new() invoked during new PCM runtime creation configures SSP by sending IPC to DSP firmware. For that to succeed device needs to be up and running. While components default probing behavior - snd_soc_catpt causing machine board module to load just after it - needs no changes, machine board's module may be unloaded and re-loaded at a different time e.g.: when catpt is already asleep. Wake device explicitly in catpt_dai_pcm_new() to ensure communication is established before sending any IPCs, enabling those advanced scenarios in the process. Signed-off-by: Cezary Rojewski <cezary.rojewski(a)intel.com> --- In short, this allows for following scenario (which user usually do not touch): 1. modprobe snd_soc_catpt // core driver 2. modprobe snd_soc_sst_broadwell // machine board driver 3. wait for snd_soc_catpt to suspend (~2s) 4. rmmod snd_soc_sst_broadwell 5. modprobe snd_soc_sst_broadwell Without the 3. everything works just fine but let's be more flexible here. Right now, -110 (timeout) will occur as device will simply be asleep. To allow for this advanced scenario, pm_runtime manipulation is required. memcmp check is to prevent unnecessary operations from occurring. sound/soc/intel/catpt/pcm.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/sound/soc/intel/catpt/pcm.c b/sound/soc/intel/catpt/pcm.c index f78018c857b8..ba653ebea7d1 100644 --- a/sound/soc/intel/catpt/pcm.c +++ b/sound/soc/intel/catpt/pcm.c @@ -667,7 +667,17 @@ static int catpt_dai_pcm_new(struct snd_soc_pcm_runtime *rtm, break; } + /* see if this is a new configuration */ + if (!memcmp(&cdev->devfmt[devfmt.iface], &devfmt, sizeof(devfmt))) + return 0; + + pm_runtime_get_sync(cdev->dev); + ret = catpt_ipc_set_device_format(cdev, &devfmt); + + pm_runtime_mark_last_busy(cdev->dev); + pm_runtime_put_autosuspend(cdev->dev); + if (ret) return CATPT_IPC_ERROR(ret); -- 2.17.1

2 2

[PATCH 0/3] ASoC: sof: cleanup Kconfig files
by Randy Dunlap 14 Oct '20

14 Oct '20

Cc: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Cc: Liam Girdwood <lgirdwood(a)gmail.com> Cc: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Cc: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Cc: Daniel Baluta <daniel.baluta(a)nxp.com> Cc: sound-open-firmware(a)alsa-project.org Cc: alsa-devel(a)alsa-project.org Some general editing of sound/soc/sof/ Kconfig files: [PATCH 1/3] ASoC: sof: imx: fix Kconfig punctuation [PATCH 2/3] ASoC: sof: intel: fix Kconfig punctuation and wording [PATCH 3/3] ASoC: sof: Kconfig: fix Kconfig punctuation and wording sound/soc/sof/Kconfig | 42 +++++++++++------------ sound/soc/sof/imx/Kconfig | 10 ++--- sound/soc/sof/intel/Kconfig | 62 +++++++++++++++++----------------- 3 files changed, 57 insertions(+), 57 deletions(-)

2 5

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
by Pavel Machek 14 Oct '20

14 Oct '20

On Wed 2020-10-14 10:22:01, Udo van den Heuvel wrote: > On 14-10-2020 10:11, Pavel Machek wrote: > >> It's a computer, not a disco-light or anything like that. > > > > And you probably have numlock LED. > > On the case? no way. > It is on the keyboard, a separate device, and already has a function. > We also have a caps lock LED and scroll lock LED there, with separate > functions. > I do not need 'extra' functionality for those. > > > Additional config options have costs, too, and we don't want to > > support gazillion config options. > > That is not the issue. > One should have thought about stuff beforehand. We did. And decided this is best solution. > The non-selectability is not my fault. It also does not affect you in any way. Feel free to go to the mic LED discussion to see why we did it like this. Then you can come up with better solution for problem at hand. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

1 0

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
by Randy Dunlap 14 Oct '20

14 Oct '20

On 10/13/20 10:16 PM, Udo van den Heuvel wrote: > On 14-10-2020 07:07, Randy Dunlap wrote: >> On 10/13/20 9:56 PM, Udo van den Heuvel wrote: > >>> I.e.: it looks like I will lose some funcionality when I disable >>> SND_HDA_CODEC_REALTEK. >> >> OK. At present you can't have it both ways, i.e., SND_HDA_CODEC_REALTEK >> with no LEDS. That driver apparently wants LEDS. > > Thanks but why have I gone for years without LEDS? > I do not need LEDS, I do not want LEDS, I do not have LEDS (that are > visible, usable, etc). > > Please make this selectable instead of forcing more bulk into my kernel. > > Kind regards, > Udo Hi Takashi, Regarding commit 7cdf8c49b1df0a385db06c4f9a5ba1b16510fdcc Author: Takashi Iwai <tiwai(a)suse.de> Date: Thu Jun 18 13:08:31 2020 +0200 ALSA: hda: generic: Add a helper for mic-mute LED with LED classdev and this Kconfig entry: config SND_HDA_CODEC_REALTEK tristate "Build Realtek HD-audio codec support" select SND_HDA_GENERIC select SND_HDA_GENERIC_LEDS it seems that LED support is not always wanted (please see above). I.e., user(s) would like to build a kernel without LED support at all. Can you make it a build option? thanks. -- ~Randy

3 8

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
by Pavel Machek 14 Oct '20

14 Oct '20

On Wed 2020-10-14 10:05:42, Udo van den Heuvel wrote: > On 14-10-2020 09:58, Pavel Machek wrote: > > Contrary to his claims, Udo very probably has LEDs in his systems... > > We have a visible power LED. > WE have a HDD LED. > The board has LEDs, yes, but the SilverStone Fortress FT02 hides them > fairly well. > I did not ask for LEDs nor need them this way. > It's a computer, not a disco-light or anything like that. And you probably have numlock LED. > Whether the code is big or not does not matter, it is a matter of being > able to select what one needs without getting bothered with other code > that will do nothing. No. Additional config options have costs, too, and we don't want to support gazillion config options. LED core should be small enough that it does not matter. Sound was inventing its own "tiny LED core" before. > So please consider. I did. Answer is no. Please accept it. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

1 0

[PATCH 1/2] Asoc: qcom: lpass-cpu: Fix clock disable failure
by Srinivasa Rao Mandadapu 14 Oct '20

14 Oct '20

From: V Sujith Kumar Reddy <vsujithk(a)codeaurora.org> Disable MI2S bit clock from PAUSE/STOP/SUSPEND usecase instead of shutdown time. Acheive this by invoking clk_disable_unprepare API from cpu daiops shutdown to cpu daiops trigger. This Fix is update to the below patch. https://lore.kernel.org/patchwork/patch/1308101/ Signed-off-by: V Sujith Kumar Reddy <vsujithk(a)codeaurora.org> Signed-off-by: Srinivasa Rao Mandadapu <srivasam(a)codeaurora.org> --- sound/soc/qcom/lpass-cpu.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c index ba2aca3..2dfb921 100644 --- a/sound/soc/qcom/lpass-cpu.c +++ b/sound/soc/qcom/lpass-cpu.c @@ -88,8 +88,6 @@ static void lpass_cpu_daiops_shutdown(struct snd_pcm_substream *substream, { struct lpass_data *drvdata = snd_soc_dai_get_drvdata(dai); - clk_disable_unprepare(drvdata->mi2s_bit_clk[dai->driver->id]); - clk_disable_unprepare(drvdata->mi2s_osr_clk[dai->driver->id]); } @@ -324,6 +322,7 @@ static int lpass_cpu_daiops_trigger(struct snd_pcm_substream *substream, if (ret) dev_err(dai->dev, "error writing to i2sctl reg: %d\n", ret); + clk_disable_unprepare(drvdata->mi2s_bit_clk[dai->driver->id]); break; } -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

2 2

Accessing pending hw_params in SND_PCM_HOOK_TYPE_HW_PARAMS call back
by alsa＠scripple.org 13 Oct '20

13 Oct '20

Hello, I'll try again with a more specific question. Is there a way one can access the hw_params that cause the SND_PCM_HOOK_TYPE_HW_PARAMS call back to be called inside the call back function? The hook only provides access to the snd_pcm_t object, but all the public calls to get hw_params fail because it's not in a prepared state yet. If there isn't a way to get them now could we please add the ability with a patch like the one below? With this patch a call to snd_pcm_hook_get_hw_params provides access to the pending hw_params structure and the pending parameters can be accessed with standard calls like snd_pcm_hw_params_get_channels. Hopefully I'm just missing how to get them without the patch, but if not they really should be made accessible. diff --git a/alsa-lib-1.1.8/include/pcm.h b/pcm.h index 5b07823..0cf5dca 100644 --- a/alsa-lib-1.1.8/include/pcm.h +++ b/pcm.h @@ -1181,6 +1181,7 @@ typedef struct _snd_pcm_hook snd_pcm_hook_t; /** PCM hook callback function */ typedef int (*snd_pcm_hook_func_t)(snd_pcm_hook_t *hook); snd_pcm_t *snd_pcm_hook_get_pcm(snd_pcm_hook_t *hook); +snd_pcm_hw_params_t *snd_pcm_hook_get_hw_params(snd_pcm_hook_t *hook); void *snd_pcm_hook_get_private(snd_pcm_hook_t *hook); void snd_pcm_hook_set_private(snd_pcm_hook_t *hook, void *private_data); int snd_pcm_hook_add(snd_pcm_hook_t **hookp, snd_pcm_t *pcm, diff --git a/alsa-lib-1.1.8/src/pcm/pcm_hooks.c b/pcm_hooks.c index 4416d36..f56c3af 100644 --- a/alsa-lib-1.1.8/src/pcm/pcm_hooks.c +++ b/pcm_hooks.c @@ -38,6 +38,7 @@ const char *_snd_module_pcm_hooks = ""; #ifndef DOC_HIDDEN struct _snd_pcm_hook { snd_pcm_t *pcm; + snd_pcm_hw_params_t *params; snd_pcm_hook_func_t func; void *private_data; struct list_head list; @@ -117,6 +118,7 @@ static int snd_pcm_hooks_hw_params(snd_pcm_t *pcm, snd_pcm_hw_params_t *params) return err; list_for_each_safe(pos, next, &h->hooks[SND_PCM_HOOK_TYPE_HW_PARAMS]) { snd_pcm_hook_t *hook = list_entry(pos, snd_pcm_hook_t, list); + hook->params = params; err = hook->func(hook); if (err < 0) return err; @@ -563,6 +565,17 @@ snd_pcm_t *snd_pcm_hook_get_pcm(snd_pcm_hook_t *hook) return hook->pcm; } +/** + * \brief Get hw_params handle for a PCM hook + * \param hook PCM hook handle + * \return hw_params handle + */ +snd_pcm_hw_params_t *snd_pcm_hook_get_hw_params(snd_pcm_hook_t *hook) +{ + assert(hook); + return hook->params; +} + /** * \brief Get callback function private data for a PCM hook * \param hook PCM hook handle @@ -609,6 +622,7 @@ int snd_pcm_hook_add(snd_pcm_hook_t **hookp, snd_pcm_t *pcm, if (!h) return -ENOMEM; h->pcm = pcm; + h->params = NULL; h->func = func; h->private_data = private_data; hooks = pcm->private_data;

1 0