August 2023 - Sound-open-firmware - mailman.alsa-project.org

Re: Getting equalizer to work on T14 Intel Gen 3 ( Alder Lake )
by Ingalsuo, Seppo 16 Aug '23

16 Aug '23

On Tue, 2023-08-08 at 17:27 +0200, Sylvain Munaut wrote: > Hi Seppo, > > > Thanks for the answer. > > I had figured out some things on my own since originally asking the > question and figured out how to create a topology file that had all > the "normal" features in my default file (deep buffer and dynamic > pipes for instance) and also add the 'eq' with a FIR and IIR in the > playback path. > > > > Warning: Do not play loud sounds from speakers to avoid damage! If > > the speaker sound is distorted, stop the playback immediately and > > drop the volume control. > > Oh wow, I didn't know that was a possibility, thanks for the warning > ! > > > > To set up equalizing this should be useful: > > > > https://thesofproject.github.io/latest/algos/eq/equalizers_tuning.html > > Yes, I've read that very attentively. Even got myself a UMIK-1 to > make > the measurements. Nice, I think it's good value for money. > > This was a quick test I made with REW (Room Eq Wizard) to capture the > response : > https://assets.chaos.social/media_attachments/files/110/735/051/339/246/082… That's a very good clean response to equalize, much better than what I saw in my T480 notebook. You could try to boost the mid frequencies with parameteric IIR EQ to not lose much of the loud bass resonance at ~800 Hz. Alternatively the FIR procedure might do everything automatically in 1k - 7k band. Cutting the lowest bass should give practical headroom and give some protection for the speaker. The speaker displacement usually increases a lot below the resonance. Hitting the displacement limits will in long term break the speaker. We don't have high-pass by default for speaker path in SOF. We could do it in platforms with separate speaker and headphone DAI but in HDA it's shared. You would need to set with sof-ctl the equalizers to pass- through when using headphones. > > I didn't get a chance yet to actually try and design filters and load > them. I'd like to do that using scipi instead of octave (just because > I like making things harder for myself apparently :) and I haven't > dug > yet into what format the configuation of the filter is. I guess I > need > to read the octave code to know what all those numbers mean. You can feed your measured response to example Octave scripts scripts and see what happens ;D Scipy seems to have a quite similar basic signal processing library as Octave and Matlab so should be possible to convert without need to re-invent everything if you like. > > > > Probably something like 2nd or 4th order high-pass around 100 - 200 > > Hz is suitable. The band 500 - 10 kHz can be likely made flatter if > > you are able to measure the frequency response. With the added > > high-pass there should be practical signal-headroom to amplify in > > the EQ with few decibels. You should be able to create a custom > > topology to use for T14 so there is no need to run sof-ctl every > > time to set up the filters. > > This was definitely an enlightening read, I must admit I had never > thought about cutting off the low frequency there was no hope to > recover to make head room to amplify/flatten the rest of the band. > > > > The DRC component is not part of the signed firmware image, but I > > hope it will be later in future. It would be useful to make the > > speaker sound louder. But EQ should already give a noticeable > > improvement. > > Ah yeah, I had seen the DRC mentioned a couple of times reading > around > SOF and was wondering if this could help too. Didn't realize of > course > you need the actual component to be present in the actual firmware > for > it to be loadable. > I do have one of those upsquared sbc as well and I seem to remember > those can load unsigned firmware so I could also use that for > experimentation. Yep, UP2, UPX, and Chromebooks in developer mode allow to run all open- source components. We don't have in git main support for UP2, but UPX with TGL platform is supported. SOF v2.2 works with UP2. We are developing also an ALSA plugin version of SOF. It will enable to run all same algorithms in main CPU user space without restrictions. Cheers, Seppo > > > Cheers, > > Sylvain --------------------------------------------------------------------- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

3 4

Re: [PATCH -next 0/2] Use devm_kmemdup to replace devm_kmalloc + memcpy
by Mark Brown 15 Aug '23

15 Aug '23

On Thu, 10 Aug 2023 19:47:36 +0800, Li Zetao wrote: > This patch set use the helper function devm_kmemdup() to replace > devm_kmalloc + memcpy, which is the same as implementing the function > separately. > > Li Zetao (2): > ASoC: tas5805m: Use devm_kmemdup to replace devm_kmalloc + memcpy > ASoC: SOF: ipc3: Use devm_kmemdup to replace devm_kmalloc + memcpy > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/2] ASoC: tas5805m: Use devm_kmemdup to replace devm_kmalloc + memcpy commit: b0a4c7f5921d9c2998bdd767a93d995786d72adc [2/2] ASoC: SOF: ipc3: Use devm_kmemdup to replace devm_kmalloc + memcpy commit: 29681184da28babc990a66e197d27ab98f2027af All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark

1 0

[PATCH] ASoC: SOF: Intel: fix hda_sdw_check_wakeen_irq()
by Arnd Bergmann 14 Aug '23

14 Aug '23

From: Arnd Bergmann <arnd(a)arndb.de> This function cannot work, as the 'chip' variable is never initialized: sound/soc/sof/intel/hda.c:423:6: error: variable 'chip' is uninitialized when used here [-Werror,-Wuninitialized] if (chip && chip->check_sdw_wakeen_irq) ^~~~ Set it the same way that other functions in this file do. Fixes: 9362ab78f175d ("ASoC: SOF: Intel: add abstraction for SoundWire wake-ups") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- There hasn't been a new linux-next in a few days, so there is a good chance someone else already fixed this in the meantime. Sending out my fix in case that hasn't happened yet. --- sound/soc/sof/intel/hda.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c index 04c748a72b137..6c9c7b390cf53 100644 --- a/sound/soc/sof/intel/hda.c +++ b/sound/soc/sof/intel/hda.c @@ -415,7 +415,7 @@ bool hda_sdw_check_wakeen_irq_common(struct snd_sof_dev *sdev) static bool hda_sdw_check_wakeen_irq(struct snd_sof_dev *sdev) { u32 interface_mask = hda_get_interface_mask(sdev); - const struct sof_intel_dsp_desc *chip; + const struct sof_intel_dsp_desc *chip = get_chip_info(sdev->pdata); if (!(interface_mask & BIT(SOF_DAI_INTEL_ALH))) return false; -- 2.39.2

2 1

[PATCH v3 0/9] sound: Use -EPROBE_DEFER instead of i915 module loading.
by Maarten Lankhorst 12 Aug '23

12 Aug '23

From: Maarten Lankhorst <dev(a)lankhorst.se> Explicitly loading i915 becomes a problem when upstreaming the new intel driver for Tiger Lake and higher graphics (xe). By loading i915, it doesn't wait for driver load of xe, and will fail completely before it loads. -EPROBE_DEFER has to be returned before any device is created in probe(), otherwise the removal of the device will cause EPROBE_DEFER to try again in an infinite loop. The conversion is done in gradual steps. First I add an argument to snd_hdac_i915_init to allow for -EPROBE_DEFER so I can convert each driver separately. Then I convert each driver to move snd_hdac_i915_init out of the workqueue. Finally I drop the ability to choose modprobe behavior after the last user is converted. I suspect the avs and skylake drivers used snd_hdac_i915_init purely for the modprobe, but I don't have the hardware to test if it can be safely removed. It can still be done easily in a followup patch to simplify probing. --- Changes since previous version: - Keep the workqueue for soc/sof/intel, instead only move out snd_hdac_i915_init. (Patch 8/9) Rest of patches unchanged. Cc: Jaroslav Kysela <perex(a)perex.cz> Cc: Takashi Iwai <tiwai(a)suse.com> Cc: Cezary Rojewski <cezary.rojewski(a)intel.com> Cc: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Cc: Liam Girdwood <liam.r.girdwood(a)linux.intel.com> Cc: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Cc: Bard Liao <yung-chuan.liao(a)linux.intel.com> Cc: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Cc: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: Daniel Baluta <daniel.baluta(a)nxp.com> Cc: alsa-devel(a)alsa-project.org Cc: linux-kernel(a)vger.kernel.org Cc: sound-open-firmware(a)alsa-project.org Maarten Lankhorst (9): ALSA: hda/intel: Fix error handling in azx_probe() ALSA: hda/i915: Allow override of gpu binding. ALSA: hda/i915: Add an allow_modprobe argument to snd_hdac_i915_init ALSA: hda/i915: Allow xe as match for i915_component_master_match ASoC: Intel: avs: Move snd_hdac_i915_init to before probe_work. ASoC: Intel: Skylake: Move snd_hdac_i915_init to before probe_work. ALSA: hda/intel: Move snd_hdac_i915_init to before probe_work. ASoC: SOF: Intel: Move binding to display driver outside of deferred probe ALSA: hda/i915: Remove extra argument from snd_hdac_i915_init sound/hda/hdac_i915.c | 25 ++++++++------- sound/pci/hda/hda_intel.c | 60 ++++++++++++++++++----------------- sound/soc/intel/avs/core.c | 13 +++++--- sound/soc/intel/skylake/skl.c | 31 ++++++------------ sound/soc/sof/core.c | 19 ++++------- 5 files changed, 70 insertions(+), 78 deletions(-) -- 2.39.2

3 18

Re: [PATCH -next] ASoC: SOF: Intel: Remove duplicated include in lnl.c
by Mark Brown 10 Aug '23

10 Aug '23

On Thu, 10 Aug 2023 08:55:55 +0800, Yang Li wrote: > ./sound/soc/sof/intel/lnl.c: hda.h is included more than once. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: SOF: Intel: Remove duplicated include in lnl.c commit: 061599c8285848fe4ec64becb278dcdd60dd3369 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark

1 0

[PATCH] ASoC: SOF: Intel: Initialize chip in hda_sdw_check_wakeen_irq()
by Nathan Chancellor 10 Aug '23

10 Aug '23

Clang warns (or errors with CONFIG_WERROR): sound/soc/sof/intel/hda.c:423:6: error: variable 'chip' is uninitialized when used here [-Werror,-Wuninitialized] 423 | if (chip && chip->check_sdw_wakeen_irq) | ^~~~ sound/soc/sof/intel/hda.c:418:39: note: initialize the variable 'chip' to silence this warning 418 | const struct sof_intel_dsp_desc *chip; | ^ | = NULL 1 error generated. Add the missing initialization, following the pattern of the other irq functions. Fixes: 9362ab78f175 ("ASoC: SOF: Intel: add abstraction for SoundWire wake-ups") Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- sound/soc/sof/intel/hda.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c index 04c748a72b13..15e6779efaa3 100644 --- a/sound/soc/sof/intel/hda.c +++ b/sound/soc/sof/intel/hda.c @@ -420,6 +420,7 @@ static bool hda_sdw_check_wakeen_irq(struct snd_sof_dev *sdev) if (!(interface_mask & BIT(SOF_DAI_INTEL_ALH))) return false; + chip = get_chip_info(sdev->pdata); if (chip && chip->check_sdw_wakeen_irq) return chip->check_sdw_wakeen_irq(sdev); --- base-commit: 59146c3cd326a622e9041614842346aada11ca99 change-id: 20230809-intel-hda-missing-chip-init-dcccbe6365a4 Best regards, -- Nathan Chancellor <nathan(a)kernel.org>

3 7

Re: [PATCH -next] ASoC: SOF: Intel: Remove duplicated include in lnl.c
by Pierre-Louis Bossart 10 Aug '23

10 Aug '23

On 8/9/23 19:55, Yang Li wrote: > ./sound/soc/sof/intel/lnl.c: hda.h is included more than once. > > Signed-off-by: Yang Li <yang.lee(a)linux.alibaba.com> yes, thanks for the patch Acked-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> > --- > sound/soc/sof/intel/lnl.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/sound/soc/sof/intel/lnl.c b/sound/soc/sof/intel/lnl.c > index 3d919b0b6891..db94b45e53af 100644 > --- a/sound/soc/sof/intel/lnl.c > +++ b/sound/soc/sof/intel/lnl.c > @@ -16,7 +16,6 @@ > #include "hda-ipc.h" > #include "../sof-audio.h" > #include "mtl.h" > -#include "hda.h" > #include <sound/hda-mlink.h> > > /* LunarLake ops */

1 0

[PATCH -next] ASoC: SOF: ipc3-dtrace: Switch to memdup_user_nul() helper
by Yang Yingliang 08 Aug '23

08 Aug '23

Use memdup_user_nul() helper instead of open-coding to simplify the code. Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- sound/soc/sof/ipc3-dtrace.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/sound/soc/sof/ipc3-dtrace.c b/sound/soc/sof/ipc3-dtrace.c index 35da85a45a9a..bd07f0472efd 100644 --- a/sound/soc/sof/ipc3-dtrace.c +++ b/sound/soc/sof/ipc3-dtrace.c @@ -196,15 +196,9 @@ static ssize_t dfsentry_trace_filter_write(struct file *file, const char __user return -EINVAL; } - string = kmalloc(count + 1, GFP_KERNEL); - if (!string) - return -ENOMEM; - - if (copy_from_user(string, from, count)) { - ret = -EFAULT; - goto error; - } - string[count] = '\0'; + string = memdup_user_nul(from, count); + if (IS_ERR(string)) + return PTR_ERR(string); ret = trace_filter_parse(sdev, string, &num_elems, &elems); if (ret < 0) -- 2.25.1

2 1

Getting equalizer to work on T14 Intel Gen 3 ( Alder Lake )
by Sylvain Munaut 08 Aug '23

08 Aug '23

Hi, So I have an alder lake laptop using ALC3287 codec. Things "work" in the sense that I get sound output from the speaker but it's of a very underwhelming quality. My understanding is that under windows there is quite a bit of EQ applied to try and get a better response from the speakers. So I'm trying to get that working under linux, but I have no idea where to even _start_. I have seen the "runtime adjustment' page on the website, but when looking at the controls I get : $ amixer -Dhw:0 controls | grep EQ numid=43,iface=MIXER,name='EQIIR10.0 eqiir_coef_10' numid=45,iface=MIXER,name='EQIIR11.0 eqiir_coef_11' numid=37,iface=MIXER,name='EQIIR2.0 eqiir_bytes_2' I get 3 IIR and not FIR. And I also have no idea what the difference is between those ... I also tried loading some eq_bass_boost settings in all of them using sof-ctl and although it does work, it doesn't change the sound output in any way as far as I can tell. So what am I doing wrong ? How can I get eq working ? I tried looking at the source code but I don't even see anything related to ALC3287 codec in there (there are others), so I'm not even sure what ends up running in my case. This is what get printed during boot : [ 17.427412] sof-audio-pci-intel-tgl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040380 [ 17.428323] sof-audio-pci-intel-tgl 0000:00:1f.3: Digital mics found on Skylake+ platform, using SOF driver [ 17.434104] sof-audio-pci-intel-tgl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040380 [ 18.738194] sof-audio-pci-intel-tgl 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 18.828369] sof-audio-pci-intel-tgl 0000:00:1f.3: use msi interrupt mode [ 18.874040] sof-audio-pci-intel-tgl 0000:00:1f.3: hda codecs found, mask 5 [ 18.874043] sof-audio-pci-intel-tgl 0000:00:1f.3: using HDA machine driver skl_hda_dsp_generic now [ 18.874046] sof-audio-pci-intel-tgl 0000:00:1f.3: DMICs detected in NHLT tables: 2 [ 18.874057] Loading firmware: intel/sof/sof-adl.ri [ 18.876222] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware info: version 2:2:0-57864 [ 18.876223] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware: ABI 3:22:1 Kernel ABI 3:23:0 [ 18.876226] sof-audio-pci-intel-tgl 0000:00:1f.3: unknown sof_ext_man header type 3 size 0x30 [ 18.989668] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware info: version 2:2:0-57864 [ 18.989671] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware: ABI 3:22:1 Kernel ABI 3:23:0 [ 19.019641] Loading firmware: intel/sof-tplg/sof-hda-generic-2ch.tplg [ 19.020671] sof-audio-pci-intel-tgl 0000:00:1f.3: Topology: ABI 3:22:1 Kernel ABI 3:23:0 [ 19.133888] input: sof-hda-dsp Mic as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input18 [ 19.133947] input: sof-hda-dsp Headphone as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input19 [ 19.133973] input: sof-hda-dsp HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input20 [ 19.134032] input: sof-hda-dsp HDMI/DP,pcm=4 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input21 [ 19.134050] input: sof-hda-dsp HDMI/DP,pcm=5 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input22 Cheers, Sylvain

2 2

Regression fix not progressing towards mainline/stable
by Thorsten Leemhuis 08 Aug '23

08 Aug '23

Hi everyone, I noticed a regression fix that afaics lingers in the thesofproject's git repo instead of progressing towards the stable trees and wondered what's up here. I'm talking about about the fix "ASoC: SOF: intel: hda: Clean up link DMA for IPC3 during stop" for this ticket: https://github.com/thesofproject/linux/issues/4455 Two more tickets about it: https://github.com/thesofproject/linux/issues/4482 https://bugzilla.kernel.org/show_bug.cgi?id=217673 It seems the fix is ready and reviewed for two weeks now, but not even in -next by now. That's not how it should be for regression fixes, as per https://docs.kernel.org/process/handling-regressions.html it ideally should be in -stable soon or already. Is this a mistake, am I missing something, or is there a good reason for this? Ciao, Thorsten

2 1