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

[PATCH] ASoC: SOF: loader: handle all SOF_IPC_EXT types
by Kai Vehmanen 24 Oct '20

24 Oct '20

From: Bard Liao <yung-chuan.liao(a)linux.intel.com> Do not emit a warning for extended firmware header fields that are not used by kernel. This creates unnecessary noise to kernel logs like: sof-audio-pci 0000:00:1f.3: warning: unknown ext header type 3 size 0x1c sof-audio-pci 0000:00:1f.3: warning: unknown ext header type 4 size 0x10 Signed-off-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski(a)linux.intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> --- sound/soc/sof/loader.c | 5 +++++ 1 file changed, 5 insertions(+) - baseline: eb5a558705c7 commit ("ASoC: mediatek: mt8183-da7219: fix DAPM paths for rt1015") diff --git a/sound/soc/sof/loader.c b/sound/soc/sof/loader.c index 68ed454f7ddf..ba9ed66f98bc 100644 --- a/sound/soc/sof/loader.c +++ b/sound/soc/sof/loader.c @@ -118,6 +118,11 @@ int snd_sof_fw_parse_ext_data(struct snd_sof_dev *sdev, u32 bar, u32 offset) case SOF_IPC_EXT_CC_INFO: ret = get_cc_info(sdev, ext_hdr); break; + case SOF_IPC_EXT_UNUSED: + case SOF_IPC_EXT_PROBE_INFO: + case SOF_IPC_EXT_USER_ABI_INFO: + /* They are supported but we don't do anything here */ + break; default: dev_warn(sdev->dev, "warning: unknown ext header type %d size 0x%x\n", ext_hdr->type, ext_hdr->hdr.size); -- 2.28.0

2 1

[PATCH] ASoC: qcom: sdm845: set driver name correctly
by Srinivas Kandagatla 24 Oct '20

24 Oct '20

With the current state of code, we would endup with something like below in /proc/asound/cards for 2 machines based on this driver. Machine 1: 0 [DB845c ]: DB845c - DB845c DB845c Machine 2: 0 [LenovoYOGAC6301]: Lenovo-YOGA-C63 - Lenovo-YOGA-C630-13Q50 LENOVO-81JL-LenovoYOGAC630_13Q50-LNVNB161216 This is not very UCM friendly both w.r.t to common up configs and card identification, and UCM2 became totally not usefull with just one ucm sdm845.conf for two machines which have different setups w.r.t HDMI and other dais. Reasons for such thing is partly because Qualcomm machine drivers never cared to set driver_name. This patch sets up driver name for the this driver to sort out the UCM integration issues! after this patch contents of /proc/asound/cards: Machine 1: 0 [DB845c ]: sdm845 - DB845c DB845c Machine 2: 0 [LenovoYOGAC6301]: sdm845 - Lenovo-YOGA-C630-13Q50 LENOVO-81JL-LenovoYOGAC630_13Q50-LNVNB161216 with this its possible to align with what UCM2 expects and we can have sdm845/DB845.conf sdm845/LENOVO-81JL-LenovoYOGAC630_13Q50-LNVNB161216.conf ... for board variants. This should scale much better! Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> --- I will post the ucm changes once this patch is merged! sound/soc/qcom/sdm845.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/qcom/sdm845.c b/sound/soc/qcom/sdm845.c index ab1bf23c21a6..6c2760e27ea6 100644 --- a/sound/soc/qcom/sdm845.c +++ b/sound/soc/qcom/sdm845.c @@ -17,6 +17,7 @@ #include "qdsp6/q6afe.h" #include "../codecs/rt5663.h" +#define DRIVER_NAME "sdm845" #define DEFAULT_SAMPLE_RATE_48K 48000 #define DEFAULT_MCLK_RATE 24576000 #define TDM_BCLK_RATE 6144000 @@ -552,6 +553,7 @@ static int sdm845_snd_platform_probe(struct platform_device *pdev) if (!data) return -ENOMEM; + card->driver_name = DRIVER_NAME; card->dapm_widgets = sdm845_snd_widgets; card->num_dapm_widgets = ARRAY_SIZE(sdm845_snd_widgets); card->dev = dev; -- 2.21.0

2 1

[PATCH 0/4] ASoC: SOF: cleanups for 5.10
by Kai Vehmanen 24 Oct '20

24 Oct '20

Series with multiple code cleanups, plus one fix to remove unnecessary kernel warnings related to firmware loading. Bard Liao (1): ASoC: SOF: loader: handle all SOF_IPC_EXT types Pierre-Louis Bossart (3): ASoC: SOF: control: remove const in sizeof() ASoC: SOF: topology: remove const in sizeof() ASoC: SOF: sof-audio: remove goto used for force-nocodec support sound/soc/sof/control.c | 20 ++++++++++---------- sound/soc/sof/loader.c | 5 +++++ sound/soc/sof/sof-audio.c | 10 +++------- sound/soc/sof/topology.c | 2 +- 4 files changed, 19 insertions(+), 18 deletions(-) -- 2.27.0

3 6

[PATCH 1/4] ALSA: hda: Refactor codec PM to use direct-complete optimization
by Kai-Heng Feng 23 Oct '20

23 Oct '20

Upon system resume, hda_codec_pm_resume() uses hda_codec_force_resume() to resume the codec. However, pm_runtime_force_resume() won't really resume the codec because of pm_runtime_need_not_resume() check. Hence, hda_codec_force_resume() schedules a jackpoll work, which is to really power up the codec. Instead of doing that, we can use direct-complete to make the PM flow more straightforward, and keep codec always suspended through system PM flow if conditions are met. On system suspend, PM core will decide what to do based on hda_codec_pm_prepare(): - If codec is not runtime-suspended, PM core will suspend and resume the device as normal. - If codec is runtime-suspended, PM core will try to keep it suspended. If it's still suspended after system resume, we use hda_codec_pm_complete() to resume codec if it's needed. Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> --- sound/pci/hda/hda_codec.c | 45 +++++++++++++++++++++++++-------------- 1 file changed, 29 insertions(+), 16 deletions(-) diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index a356c21edb90..c2a510cc81bb 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -2934,7 +2934,7 @@ static void hda_call_codec_resume(struct hda_codec *codec) snd_hdac_leave_pm(&codec->core); } -static int hda_codec_runtime_suspend(struct device *dev) +static int hda_codec_suspend(struct device *dev) { struct hda_codec *codec = dev_to_hda_codec(dev); unsigned int state; @@ -2953,7 +2953,7 @@ static int hda_codec_runtime_suspend(struct device *dev) return 0; } -static int hda_codec_runtime_resume(struct device *dev) +static int hda_codec_resume(struct device *dev) { struct hda_codec *codec = dev_to_hda_codec(dev); @@ -2967,57 +2967,70 @@ static int hda_codec_runtime_resume(struct device *dev) pm_runtime_mark_last_busy(dev); return 0; } + +static int hda_codec_runtime_suspend(struct device *dev) +{ + return hda_codec_suspend(dev); +} + +static int hda_codec_runtime_resume(struct device *dev) +{ + return hda_codec_resume(dev); +} + #endif /* CONFIG_PM */ #ifdef CONFIG_PM_SLEEP -static int hda_codec_force_resume(struct device *dev) +static int hda_codec_pm_prepare(struct device *dev) +{ + return pm_runtime_suspended(dev); +} + +static void hda_codec_pm_complete(struct device *dev) { struct hda_codec *codec = dev_to_hda_codec(dev); - int ret; - ret = pm_runtime_force_resume(dev); - /* schedule jackpoll work for jack detection update */ - if (codec->jackpoll_interval || - (pm_runtime_suspended(dev) && hda_codec_need_resume(codec))) - schedule_delayed_work(&codec->jackpoll_work, - codec->jackpoll_interval); - return ret; + if (pm_runtime_suspended(dev) && + (hda_codec_need_resume(codec) || codec->forced_resume)) + pm_request_resume(dev); } static int hda_codec_pm_suspend(struct device *dev) { dev->power.power_state = PMSG_SUSPEND; - return pm_runtime_force_suspend(dev); + return hda_codec_suspend(dev); } static int hda_codec_pm_resume(struct device *dev) { dev->power.power_state = PMSG_RESUME; - return hda_codec_force_resume(dev); + return hda_codec_resume(dev); } static int hda_codec_pm_freeze(struct device *dev) { dev->power.power_state = PMSG_FREEZE; - return pm_runtime_force_suspend(dev); + return hda_codec_suspend(dev); } static int hda_codec_pm_thaw(struct device *dev) { dev->power.power_state = PMSG_THAW; - return hda_codec_force_resume(dev); + return hda_codec_resume(dev); } static int hda_codec_pm_restore(struct device *dev) { dev->power.power_state = PMSG_RESTORE; - return hda_codec_force_resume(dev); + return hda_codec_resume(dev); } #endif /* CONFIG_PM_SLEEP */ /* referred in hda_bind.c */ const struct dev_pm_ops hda_codec_driver_pm = { #ifdef CONFIG_PM_SLEEP + .prepare = hda_codec_pm_prepare, + .complete = hda_codec_pm_complete, .suspend = hda_codec_pm_suspend, .resume = hda_codec_pm_resume, .freeze = hda_codec_pm_freeze, -- 2.17.1

3 12

[PATCH] ASoC: Intel: Enable coredump in kconfig
by Gustaw Lewandowski 23 Oct '20

23 Oct '20

From: Piotr Maziarz <piotrx.maziarz(a)linux.intel.com> WANT_DEV_COREDUMP flag is needed here if this driver is only one using dev_coredump feature. Signed-off-by: Piotr Maziarz <piotrx.maziarz(a)linux.intel.com> Signed-off-by: Gustaw Lewandowski <gustaw.lewandowski(a)linux.intel.com> --- sound/soc/intel/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig index a5b446d5af19..c215156e2e18 100644 --- a/sound/soc/intel/Kconfig +++ b/sound/soc/intel/Kconfig @@ -4,6 +4,7 @@ config SND_SOC_INTEL_SST_TOPLEVEL default y depends on X86 || COMPILE_TEST select SND_SOC_INTEL_MACH + select WANT_DEV_COREDUMP help Intel ASoC SST Platform Drivers. If you have a Intel machine that has an audio controller with a DSP and I2S or DMIC port, then -- 2.29.0

2 1

Re: [alsa-cvslog] [ALSA GIT]ALSA utilities repository branch master updated. v1.2.4-1-g0c5948e
by Takashi Iwai 23 Oct '20

23 Oct '20

On Fri, 23 Oct 2020 11:41:25 +0200, GIT server wrote: > > This is an automated email from the git hooks/post-receive script. It was > generated because a ref change was pushed to the repository containing > the project "ALSA utilities repository". > > The branch, master has been updated > via 0c5948e98a6a8535c89b7bcab13017d7732181c6 (commit) > from b2ae0b074669f976c53a52bcd0129227321f88c9 (commit) > > Those revisions listed above that are new to this repository have > not appeared on any other notification email; so we list those > revisions in full, below. > > - Log ----------------------------------------------------------------- > commit 0c5948e98a6a8535c89b7bcab13017d7732181c6 > Author: Hui Wang <hui.wang(a)canonical.com> > Date: Fri Oct 23 16:47:10 2020 +0800 > > aplay: try to use 16-bit format to increase capture quality > > Recently users reported a bug, I tested it and found it is a common > issue on Laptop or Desktop machines. > > The issue is users plug a headset and use "arecord test.wav" to > record a sound with default input volume, the recorded sound has > poor quality and nearly can't distinguish it is the sound we want > to record. > > This is because the input volume is low and the default format is U8. > The driver records sound with 16bit, because the input volume is low, > most of samples are within (-256,+256), when converting 16bit to U8, > those samples will be 0x7f. This is called quantization noise and we > could only workaround it by increase the input volume or adding -f to > arecord. > > But users want to record a better quality sound with default input > volume (after installing a new OS, the volume is the default volume), > and they don't want to add parameters to the arecord because most of > new linux users just use "arecord test.wav". > > So this patch tries to change the default format from U8 to S16_LE/BE. > If the machine doesn't support S16_LE/BE, it still uses U8 as default > format. > > Signed-off-by: Hui Wang <hui.wang(a)canonical.com> > Signed-off-by: Jaroslav Kysela <perex(a)perex.cz> This brought a slight concern about the compatibility, as the tool is very old and used in many places. But a right usage is always with the proper option, so maybe this won't break too many things (hopefully). Though, this change made me wonder why we don't have any default configuration for aplay/arecord. With that, you can adjust it per user or per distro. Would it bring more benefit? thanks, Takashi

1 0

PA - snd_pcm_avail() returned a value that is exceptionally large
by GitHub issues - edited 23 Oct '20

23 Oct '20

alsa-project/alsa-lib issue #68 was edited from reezer: I hope this is the right place to report this. This occurred in relation to a crash. http://alsa-project.org/db/?f=52e8505d884682fc06adac4ab8ce92a4ca3e0870 ``` E: [alsa-sink-ALC887-VD Analog] alsa-util.c: snd_pcm_avail() returned a value that is exceptionally large: 177312 bytes (923 ms). E: [alsa-sink-ALC887-VD Analog] alsa-util.c: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers. E: [alsa-sink-ALC887-VD Analog] alsa-util.c: snd_pcm_dump(): E: [alsa-sink-ALC887-VD Analog] alsa-util.c: Soft volume PCM E: [alsa-sink-ALC887-VD Analog] alsa-util.c: Control: PCM Playback Volume E: [alsa-sink-ALC887-VD Analog] alsa-util.c: min_dB: -51 E: [alsa-sink-ALC887-VD Analog] alsa-util.c: max_dB: 0 E: [alsa-sink-ALC887-VD Analog] alsa-util.c: resolution: 256 E: [alsa-sink-ALC887-VD Analog] alsa-util.c: Its setup is: E: [alsa-sink-ALC887-VD Analog] alsa-util.c: stream : PLAYBACK E: [alsa-sink-ALC887-VD Analog] alsa-util.c: access : MMAP_INTERLEAVED E: [alsa-sink-ALC887-VD Analog] alsa-util.c: format : S16_LE E: [alsa-sink-ALC887-VD Analog] alsa-util.c: subformat : STD E: [alsa-sink-ALC887-VD Analog] alsa-util.c: channels : 2 E: [alsa-sink-ALC887-VD Analog] alsa-util.c: rate : 48000 E: [alsa-sink-ALC887-VD Analog] alsa-util.c: exact rate : 48000 (48000/1) E: [alsa-sink-ALC887-VD Analog] alsa-util.c: msbits : 16 E: [alsa-sink-ALC887-VD Analog] alsa-util.c: buffer_size : 4800 ``` Issue URL : https://github.com/alsa-project/alsa-lib/issues/68 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

PA poll wakeup issue (was: bug in the ALSA driver 'snd_hda_intel')
by GitHub issues - edited 23 Oct '20

23 Oct '20

alsa-project/alsa-lib issue #90 was edited from Mysgym: Hello, after spending some time troubleshooting an issue with an audio interface (using snd_hda_intel). I've stumbled upon this message from PulseAudio in the journal : `Oct 17 18:30:58 LaptopName pulseaudio[1782]: E: [alsa-sink-ALC256 Analog] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write. Oct 17 18:30:58 LaptopName pulseaudio[1782]: E: [alsa-sink-ALC256 Analog] alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers. Oct 17 18:30:58 LaptopName pulseaudio[1782]: E: [alsa-sink-ALC256 Analog] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. ` So I filed a bug report This is Manjaro on Kernel 5.8 Issue URL : https://github.com/alsa-project/alsa-lib/issues/90 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

aplay: try to use 16-bit format to increase capture quality
by GitHub pull_request - opened 23 Oct '20

23 Oct '20

alsa-project/alsa-utils pull request #69 was opened from jason77-wang: Recently users reported a bug, I tested it and found it is a common issue on Laptop or Desktop machines. The issue is users plug a headset and use "arecord test.wav" to record a sound with default input volume, the recorded sound has poor quality and nearly can't distinguish it is the sound we want to record. This is because the input volume is low and the default format is U8. The driver records sound with 16bit, because the input volume is low, most of samples are within (-256,+256), when converting 16bit to U8, those samples will be 0x7f. This is called quantization noise and we could only workaround it by increase the input volume or adding -f to arecord. But users want to record a better quality sound with default input volume (after installing a new OS, the volume is the default volume), and they don't want to add parameters to the arecord because most of new linux users just use "arecord test.wav". So this patch tries to change the default format from U8 to S16_LE/BE. If the machine doesn't support S16_LE/BE, it still uses U8 as default format. Signed-off-by: Hui Wang <hui.wang(a)canonical.com> Request URL : https://github.com/alsa-project/alsa-utils/pull/69 Patch URL : https://github.com/alsa-project/alsa-utils/pull/69.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

[alsa-devel mailing list / gmail] Re: Excessive bounces
by Jaroslav Kysela 23 Oct '20

23 Oct '20

Dne 21. 10. 20 v 23:09 Eu, acc napsal(a): > Dear Sir > > I received an email to confirm membership on alsa-devel list. > > I have doubled checked configuration, possible invasion of my systems. It is > strange because I use Gmail for reading the list, there is more than 5 GB of > available space, and not other reason for the bounces. > > The only curious point is that email from several regular developers, even > Jaroslav at a time, are classified as spam by gmail. I tried to discover the > reason in the past, but the explanation from Google is that there seems to be > a lot of spam in alada-devel and and alsa-users lists. I need the real examples (for alsa-devel). The alsa-users mailing list is on sourceforge and probably dead. > Thanks and keep the good work. [Cc: to alsa-devel] I'm sorry, but it seems that gmail changed something before several weeks for incoming e-mail and they have weird message rate limit rules for IP address and content classification. It basically does not work for the mailing list. I already tried to contact their support, but I've not received any answer. I already implemented all protections like DKIM, DMARC, SFP. Verified today using a dmarc report analyzer tool. Unfortunately, I cannot do much here. I can assist to fix the issues, but I need to know, what I can improve. I suggest to use another e-mail service. It seems that google does not care about users now. Or you should ask them what's exactly wrong. The current postmaster.google.com stats for alsa-project.org: User reported spam rate - 0% DKIM, DMARC, SFP success rate - all 100% Encryption - 100% IP reputation - bad Delivery errors - 40% - 100% Jaroslav -- Jaroslav Kysela <perex(a)perex.cz> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

2 1