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

More Generic Audio Graph Sound Card idea
by Kuninori Morimoto 16 Oct '20

16 Oct '20

Hi Mark Cc Pierre-Louis, Sameer Current audio-graph-card driver has DPCM support, but it is limited (= Mix/Mux/TDM-split/rate-convert/channel-convert). It was expanded forcibly expanded. Because of it, the connection judgement for normal vs DPCM is tricky. I know Pierre-Louis want to use it for SOF, but something is missing, thus, can't use (?). I know now Sameer is currently trying to expand it now. It is OK for me, but, more expansion in the future will be difficult/buggy. For example supporting many *generic* DPCM and normal connection in the same time will be difficult. I'm thinking below style as new audio-graph-card2. It is not tricky, thus connection judgement for normal vs DSP is easy. Then, code can be more readable (= no guaranty :P) ? I guss "audio-graph-card" and "audio-graph-card2" can have some (= not full) compatible for normal connection. But has no compatible for DPCM connection. I think I need to keep as-is for current audio-graph-card, and create new audio-graph-card2 driver. Because there is users, and card2 implementation will have huge different. Keeping compatible and update will be very difficult or buggy. But what do you think ? Note 1 is that this is just idea for now. I'm very happy to implement it, but it will be after that my all remaining patch was posted/accepted. Note 2 is that I'm not full DPCM analyst. Thus, maybe audio-graph-card2 can solve current connection issue, but might can't for unknown connection case. In such came we need ver3 (?). ------------ image --------------------------- | Front End PCMs | SoC DSP | Back End DAIs | Audio devices | ************* PCM0 <------------> * * <----DAI0-----> Codec Headset * * PCM1 <------------> * * <----DAI1-----> Codec Speakers * DSP * PCM2 <------------> * * <----DAI2-----> MODEM * * PCM3 <------------> * * <----DAI3-----> BT * * * * <----DAI4-----> DMIC * * * * <----DAI5-----> FM ************* ------------ DT sample --------------------------- sound { compatible = "audio-graph-card2"; dais = <&pcm0, &pcm1, &pcm2, &pcm3>; }; front-end { ports { pcm0: port@0 { pcm0_endpoint: endpoint { remote-endpoint = <&dsp_f0>; }; }; pcm1: port@1 { pcm1_endpoint: endpoint { remote-endpoint = <&dsp_f1>; }; }; pcm2: port@2 { pcm2_endpoint: endpoint { remote-endpoint = <&dsp_f2>; }; }; pcm3: port@3 { pcm3_endpoint: endpoint { remote-endpoint = <&dsp_f3>; }; }; }; }; dsp { compatible = "audio-graph-card2-dsp"; ports { /* Front End side */ port@0 { dsp_f0: endpoint { remote-endpoint = <&pcm0>; }; }; port@1 { dsp_f1: endpoint { remote-endpoint = <&pcm1>; }; }; port@2 { dsp_f2: endpoint { remote-endpoint = <&pcm2>; }; }; port@3 { dsp_f3: endpoint { remote-endpoint = <&pcm3>; }; }; /* Back End side */ port@4 { dsp_b0: endpoint { remote-endpoint = <&dai0>; }; }; port@5 { dsp_b1: endpoint { remote-endpoint = <&dai1>; }; }; port@6 { dsp_b2: endpoint { remote-endpoint = <&dai2>; }; }; port@7 { dsp_b3: endpoint { remote-endpoint = <&dai3>; }; }; port@8 { dsp_b4: endpoint { remote-endpoint = <&dai4>; }; }; port@9 { dsp_b5: endpoint { remote-endpoint = <&dai5>; }; }; }; }; back-end { ports { port@0 { dai0: endpoint { remote-endpoint = <&dsp_b0>; }; }; port@1 { dai1: endpoint { remote-endpoint = <&dsp_b1>; }; }; port@2 { dai2: endpoint { remote-endpoint = <&dsp_b2>; }; }; port@3 { dai3: endpoint { remote-endpoint = <&dsp_b3>; }; }; port@4 { dai4: endpoint { remote-endpoint = <&dsp_b4>; }; }; port@5 { dai5: endpoint { remote-endpoint = <&dsp_b5>; }; }; }; };

5 30

amixer: cset: check control is readable before reading it
by GitHub pull_request - opened 15 Oct '20

15 Oct '20

alsa-project/alsa-utils pull request #63 was opened from ViorelSuman: In current implementation cset command will fail on controls which are not readable, ie just writable. Check readable state prior calling snd_ctl_elem_read. Signed-off-by: Viorel Suman <viorel.suman(a)nxp.com> Request URL : https://github.com/alsa-project/alsa-utils/pull/63 Patch URL : https://github.com/alsa-project/alsa-utils/pull/63.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

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