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

[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

Re: [PATCH v3 00/10] Auxiliary bus implementation and SOF multi-client support
by Greg KH 23 Oct '20

23 Oct '20

On Fri, Oct 23, 2020 at 09:49:46AM +0300, Leon Romanovsky wrote: > On Thu, Oct 22, 2020 at 05:33:28PM -0700, Dave Ertman wrote: > > <...> > > > Dave Ertman (1): > > Add auxiliary bus support > > We are in merge window now and both netdev and RDMA are closed for > submissions. So I'll send my mlx5 conversion patches once -rc1 will > be tagged. > > However, It is important that this "auxiliary bus" patch will be applied > to some topic branch based on Linus's -rcX. It will give us an ability > to pull this patch to RDMA, VDPA and netdev subsystems at the same time. I will do that, but as you said, it's the middle of the merge window and I can't do anything until after -rc1 is out. Give us some time to catch up after that... greg k-h

1 0

on-board sound on ASUS TRX-40
by Dan Aloni 22 Oct '20

22 Oct '20

Hi, The on-board earphone jack does not seem to work on an ASUS TRX-40 board. Here's the alsa-info.sh output: http://alsa-project.org/db/?f=7a94c1b1eec4b2e623c75770364ec43c33d6c95c Tried coding up the patch below, but it _does not_ fix the problem. It does shows the earphone as 'plugged' though. Verified that it's not an hardware issue via Windows. Please instruct on how to debug this further. Thanks! diff --git a/sound/usb/mixer_maps.c b/sound/usb/mixer_maps.c index 9af7aa93f6fa..ab0f036f385e 100644 --- a/sound/usb/mixer_maps.c +++ b/sound/usb/mixer_maps.c @@ -568,6 +568,10 @@ static const struct usbmix_ctl_map usbmix_ctl_maps[] = { .map = trx40_mobo_map, .connector_map = trx40_mobo_connector_map, }, + { /* ASUS TRX40-PRO */ + .id = USB_ID(0x0b05, 0x1918), + .map = trx40_mobo_map, + }, { /* Asrock TRX40 Creator */ .id = USB_ID(0x26ce, 0x0a01), .map = trx40_mobo_map, -- Dan Aloni

2 10