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

[Sound-open-firmware] Changing Fedora 34 default driver for BYT + CHT back to SST?
by Hans de Goede 19 Mar '21

19 Mar '21

Hi All, First of all this is NOT intended as a way to get more attention to recently noticed BYT/CHT bugs. I realize it may feel that way but that is not my intention. My goal of this email is to have a honest discussion about what will be the best driver to use by default for BYT/CHT for Fedora 34. With that said, there are a number of SOF related issues with audio on BYT/CHT devices, some recent issues and one issue which is fixed, but only in 1.7 for which no release has been made yet: "[BUG][BYT][CHT] Output channel left/right swap on various BYT/CHT devices with various codecs" https://github.com/thesofproject/sof/issues/3699 Status: Fixed in master, but still present in latest sof-bin release (1.6.1) "[BUG][BYT][CHT] Linux 5.11 Cherrytrail/rt5640 emits persistent beeping sound after a short while" https://github.com/thesofproject/sof/issues/3868 Status: Still being investigated. "[BUG][CHT] loud crackle from speakers at boot, which does not happen with SST driver" https://github.com/thesofproject/sof/issues/3932 Status: Still being investigated. "[BUG][BYT] SOF hangs, logger shows "dw_dma_start(): dma 1 channel 1 not ready" error" https://github.com/thesofproject/sof/issues/3937 Status: Still being investigated, configuring pipewire to use 16 bits samples seems to be a workaround (but I did manage to trigger 3868 in that configuration) The crackle is more of an annoyance then a blocker (but it is quite annoying), but the 2 beep/hang bugs are kinda showstoppers IMHO. As such ATM I believe that the best way forward is for me to flip the default for Fedora 34 back to SST during the coming week (before the final freeze kicks in) and then to try again with Fedora 35. Regards, Hans

3 3

[Sound-open-firmware] Fallback on failed custom firmware loading
by Curtis Malainey 25 Feb '21

25 Feb '21

Hello Pierre, I was wondering if this feature would be ok with you. We are working to start switching out various firmware files using command line boot params. Given we are doing this in AP firmware, we have no indication of what is in the OS and if the device has been loaded with a non-standard image. We clearly don't want to break audio for users who are running vanilla linux on these machines. So what my proposal is, if a firmware/topology path is passed in via module params is not found, that we fall back to the next method (dmi check) and lastly using the default rather than doing a one shot method. What are your thoughts here?

1 0

Re: [Sound-open-firmware] codec_adapter local buffer
by Daniel Baluta 19 Feb '21

19 Feb '21

Hi Marcin, Thanks for your answer. Few comments inline. > > > > What is the exact usage of local buffer in codec_adapter component? > > > [Marcin Rajwa] with current implementation the local buffer plays a crucial role when codec input buffer is different than the pipeline period. In this case, we need to store enough samples before we actually start producing samples outside otherwise we are prone to glitches. > > Commit below says: > > commit 44137fad6c4a8e5dbf4ae8a959885086f3a81748 > > codec_adapter: add local buffer > > > > This patch adds local buffer to codec adapter. The aim of > > this buffer is to damp any irregularity between pipeline > > and codec. The difference in buffer sizes is one of the > > examples here - thanks to additional local buffer we can > > call codec processing several times during one period or > > we can store several pipeline periods in local buffer and > > process them once. > > > > In case of decoder algorithms. Is this used as an input or output buffer? > > > [Marcin Rajwa] well as you know, no decoding/encoding functionality is officially supported yet. However this buffer is supposed to be an output. Your input buffer is really a source buffer of codec_adapter defined in the topology. Make sure to make it big enough so it can store all samples needed to start decoding. Now, imagine you have decoded four period of samples (this is the starting threshold), you produced them all to the DAI and what's going to happen next? Next you will produce nothing in following four periods, so DAI will report underruns .. the issue is apparent. So here local buffer alongside with deep buffering feature of codec_adapter comes in as a cure - you decode samples to local buffer but produce them out only when we calleted sufficient amount, so we can ensure each pipeline period will get its period data. DB: I am trying to add decoding functionality on top of your codec_adapter code. The only difference now is that now (just as an example) for X bytes of input compressed data I get 10 X bytes at output of PCM data. So, I need to find a good balance between source buffer size, local output buffer size and the moment when I should call process function. It looks like now deep buffering only happens at the start of stream, then cd->deep_buff_bytes is set to 0 comp_dbg(dev, "codec_adapter_copy(): deep buffering has ended after gathering %d bytes of processed data", audio_stream_get_avail_bytes(&local_buff->stream)); cd->deep_buff_bytes = 0; and then never changed. I will add a topic about compress decoding for our next week meeting.

1 0

[Sound-open-firmware] codec_adapter local buffer
by Daniel Baluta 19 Feb '21

19 Feb '21

Hi Marcin, What is the exact usage of local buffer in codec_adapter component? Commit below says: commit 44137fad6c4a8e5dbf4ae8a959885086f3a81748 codec_adapter: add local buffer This patch adds local buffer to codec adapter. The aim of this buffer is to damp any irregularity between pipeline and codec. The difference in buffer sizes is one of the examples here - thanks to additional local buffer we can call codec processing several times during one period or we can store several pipeline periods in local buffer and process them once. In case of decoder algorithms. Is this used as an input or output buffer? Looking at: ` we can store several pipeline periods in local buffer and process them once` it looks to be an input buffer. But looking at code it looks like it is used as an temporary output buffer.

1 0

[Sound-open-firmware] NXP 8M Plus platform suitable for SOF getting started
by martin.roessler＠roessler-netz.de 14 Feb '21

14 Feb '21

Hello SOF Team, I would like to get started with SOF: I'm interested in audio signal processing, audio driver programming and hardware. I do this to some extend during my normal work, however, for new things to learn there is never time. So, I’m looking for a suitable NXP board for SOF. I would like to use the new i.MX8M Plus if possible or is it better to use one of the NXP platforms mention in the sof documentation? I could not find any NXP "native" 8M Plus board on the web page, however, there is a device tree file imx8mp-evk-sof-wm8960.dts indicating there is one? All 3rd party 8M Plus board vendors I contacted so far are not so familiar with the Hifi4 core, so not much help, especially when asking about JTAG access to this core. Could you give any recommendation of a not so expensive board (> ~ 500 US$) suitable for SOF? Also I'm unclear how to get technical information of the Hifi4 core. Nothing mentioned in the SOC datasheets so far. I could use one of the Tensilica licenses of my company I work for. But do I need to contact NXP or Cadence?. Any NDA required? I have already a i.MX 8M Mini EVK for Android learning and a i.MX RT600 EVK just for fun. So, just a maybe stupid question: Any plans to support SOF together with a "normal" Cortex-M4 / Cortex-M7 accelerator core on the (NXP) SOCs? Now that it is possible to use Zephyr as RTOS, I think this would be possible, at least for some not too complex audio pipelines. Thanks for some help. Regards Martin

2 2

[Sound-open-firmware] [PATCH AUTOSEL 5.4 08/19] ASoC: SOF: Intel: hda: Resume codec to do jack detection
by Sasha Levin 29 Jan '21

29 Jan '21

From: Kai-Heng Feng <kai.heng.feng(a)canonical.com> [ Upstream commit bcd7059abc19e6ec5b2260dff6a008fb99c4eef9 ] Instead of queueing jackpoll_work, runtime resume the codec to let it use different jack detection methods based on jackpoll_interval. This partially matches SOF driver's behavior with commit a6e7d0a4bdb0 ("ALSA: hda: fix jack detection with Realtek codecs when in D3"), the difference is SOF unconditionally resumes the codec. Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Link: https://lore.kernel.org/r/20210112181128.1229827-1-kai.heng.feng@canonical.… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/intel/hda-codec.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/sof/intel/hda-codec.c b/sound/soc/sof/intel/hda-codec.c index 9e8233c10d860..df38616c431a6 100644 --- a/sound/soc/sof/intel/hda-codec.c +++ b/sound/soc/sof/intel/hda-codec.c @@ -68,8 +68,7 @@ void hda_codec_jack_check(struct snd_sof_dev *sdev) * has been recorded in STATESTS */ if (codec->jacktbl.used) - schedule_delayed_work(&codec->jackpoll_work, - codec->jackpoll_interval); + pm_request_resume(&codec->core.dev); } #else void hda_codec_jack_wake_enable(struct snd_sof_dev *sdev) {} -- 2.27.0

1 0

[Sound-open-firmware] [PATCH AUTOSEL 5.10 12/41] ASoC: SOF: Intel: hda: Resume codec to do jack detection
by Sasha Levin 29 Jan '21

29 Jan '21

From: Kai-Heng Feng <kai.heng.feng(a)canonical.com> [ Upstream commit bcd7059abc19e6ec5b2260dff6a008fb99c4eef9 ] Instead of queueing jackpoll_work, runtime resume the codec to let it use different jack detection methods based on jackpoll_interval. This partially matches SOF driver's behavior with commit a6e7d0a4bdb0 ("ALSA: hda: fix jack detection with Realtek codecs when in D3"), the difference is SOF unconditionally resumes the codec. Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Link: https://lore.kernel.org/r/20210112181128.1229827-1-kai.heng.feng@canonical.… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/intel/hda-codec.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/sof/intel/hda-codec.c b/sound/soc/sof/intel/hda-codec.c index 8b0ddc4b8227b..8d65004c917a1 100644 --- a/sound/soc/sof/intel/hda-codec.c +++ b/sound/soc/sof/intel/hda-codec.c @@ -93,8 +93,7 @@ void hda_codec_jack_check(struct snd_sof_dev *sdev) * has been recorded in STATESTS */ if (codec->jacktbl.used) - schedule_delayed_work(&codec->jackpoll_work, - codec->jackpoll_interval); + pm_request_resume(&codec->core.dev); } #else void hda_codec_jack_wake_enable(struct snd_sof_dev *sdev) {} -- 2.27.0

1 0

[Sound-open-firmware] Adding more clients to the KPB draining task
by Cristina Feies (ilie) 26 Jan '21

26 Jan '21

Hi all, I would like to add new client for the draining task in KPB component. I observed there is a register function and init_draining receives a parameter with all the client data. However in init_draining when the draining_task is created the draining sink is fixed to host sink and is not read from the client parameter. Moreover I see that when draining data from history buffer on host sink(kpb_drain_samples function), the read pointer (r_ptr) of the history buffer is advanced. So we consume this buffer from the first client. Is there a patch which addresses multiple clients for the draining task? I would like to add the keyword detection component as client of the KPB draining task but this would be the second customer, after the host. Thank you, Cristina

1 0

[Sound-open-firmware] amixer pipeline issues
by Daniel Baluta 25 Jan '21

25 Jan '21

Hi Pierre, We are experiencing issues using mixer piplines. I think it is the same issue mentioned here: https://github.com/thesofproject/sof/issues/3171 We get the issue for all formats: S{16|24|32}_LE At some point aplay stops with I/O write error. This PR: https://github.com/plbossart/sof/commit/baed1f0283f190e319444d06cdfc7f7c78a… doesn't fix the issues as it seems it does for Intel. We are investigating and suspecting it might be a wild scheduling issue, anyway I have a generic question about this scenario. Looking at sof-cht-max98090.m4 we have 3 pipelines involved in the playback: -> [pipeline 1] -> playback DAI using 2 periods -> [pipeline 3] -> playback pipeline 3 on PCM 0 with 1ms deadline -> [pipeline 4] -> playback pipeline 4 on PCM 1 with 10ms deadline. The question is why pipeline 3 and pipeline 4 are not symmetrical, meaning that they should have the same period size. But one has 1ms and the other one has 10ms. What's the idea behind this?

2 1

[Sound-open-firmware] [PATCH 1/2] [v2] ALSA: hda: fix SND_INTEL_DSP_CONFIG dependency
by Arnd Bergmann 14 Jan '21

14 Jan '21

From: Arnd Bergmann <arnd(a)arndb.de> The sof-pci-dev driver fails to link when built into the kernel and CONFIG_SND_INTEL_DSP_CONFIG is set to =m: arm-linux-gnueabi-ld: sound/soc/sof/sof-pci-dev.o: in function `sof_pci_probe': sof-pci-dev.c:(.text+0x1c): undefined reference to `snd_intel_dsp_driver_probe' All other drivers using this interface already use a 'select SND_INTEL_DSP_CONFIG' statement to force the it to be present, so it seems reasonable to do the same here. The stub implementation in the header makes the problem harder to find, as it avoids the link error when SND_INTEL_DSP_CONFIG is completely disabled, without any obvious upsides. Remove these stubs to make it clearer that the driver is in fact needed here. Fixes: 82d9d54a6c0e ("ALSA: hda: add Intel DSP configuration / probe code") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- v2: fix various build issues in the first version, now passes all randconfig builds I tried --- include/sound/intel-dsp-config.h | 17 ----------------- sound/soc/sof/Kconfig | 2 ++ sound/soc/sof/intel/Kconfig | 4 ++-- sound/soc/sof/intel/byt.c | 2 +- 4 files changed, 5 insertions(+), 20 deletions(-) diff --git a/include/sound/intel-dsp-config.h b/include/sound/intel-dsp-config.h index d4609077c258..94667e870029 100644 --- a/include/sound/intel-dsp-config.h +++ b/include/sound/intel-dsp-config.h @@ -18,24 +18,7 @@ enum { SND_INTEL_DSP_DRIVER_LAST = SND_INTEL_DSP_DRIVER_SOF }; -#if IS_ENABLED(CONFIG_SND_INTEL_DSP_CONFIG) - int snd_intel_dsp_driver_probe(struct pci_dev *pci); int snd_intel_acpi_dsp_driver_probe(struct device *dev, const u8 acpi_hid[ACPI_ID_LEN]); -#else - -static inline int snd_intel_dsp_driver_probe(struct pci_dev *pci) -{ - return SND_INTEL_DSP_DRIVER_ANY; -} - -static inline -int snd_intel_acpi_dsp_driver_probe(struct device *dev, const u8 acpi_hid[ACPI_ID_LEN]) -{ - return SND_INTEL_DSP_DRIVER_ANY; -} - -#endif - #endif diff --git a/sound/soc/sof/Kconfig b/sound/soc/sof/Kconfig index 031dad5fc4c7..051fd3d27047 100644 --- a/sound/soc/sof/Kconfig +++ b/sound/soc/sof/Kconfig @@ -12,6 +12,7 @@ if SND_SOC_SOF_TOPLEVEL config SND_SOC_SOF_PCI tristate "SOF PCI enumeration support" depends on PCI + select SND_INTEL_DSP_CONFIG select SND_SOC_SOF select SND_SOC_ACPI if ACPI help @@ -23,6 +24,7 @@ config SND_SOC_SOF_PCI config SND_SOC_SOF_ACPI tristate "SOF ACPI enumeration support" depends on ACPI || COMPILE_TEST + select SND_INTEL_DSP_CONFIG select SND_SOC_SOF select SND_SOC_ACPI if ACPI select IOSF_MBI if X86 && PCI diff --git a/sound/soc/sof/intel/Kconfig b/sound/soc/sof/intel/Kconfig index ff9266413a06..67365ce0d86d 100644 --- a/sound/soc/sof/intel/Kconfig +++ b/sound/soc/sof/intel/Kconfig @@ -53,7 +53,7 @@ config SND_SOC_SOF_INTEL_COMMON if SND_SOC_SOF_ACPI config SND_SOC_SOF_BAYTRAIL - bool "SOF support for Baytrail, Braswell and Cherrytrail" + tristate "SOF support for Baytrail, Braswell and Cherrytrail" select SND_SOC_SOF_INTEL_ATOM_HIFI_EP select SND_INTEL_DSP_CONFIG help @@ -70,7 +70,7 @@ config SND_SOC_SOF_BAYTRAIL If unsure select "N". config SND_SOC_SOF_BROADWELL - bool "SOF support for Broadwell" + tristate "SOF support for Broadwell" select SND_INTEL_DSP_CONFIG select SND_SOC_SOF_INTEL_COMMON select SND_SOC_SOF_INTEL_HIFI_EP_IPC diff --git a/sound/soc/sof/intel/byt.c b/sound/soc/sof/intel/byt.c index 65abcca94521..42dba3da1ca3 100644 --- a/sound/soc/sof/intel/byt.c +++ b/sound/soc/sof/intel/byt.c @@ -660,7 +660,7 @@ EXPORT_SYMBOL_NS(tng_chip_info, SND_SOC_SOF_MERRIFIELD); #endif /* CONFIG_SND_SOC_SOF_MERRIFIELD */ -#ifdef CONFIG_SND_SOC_SOF_BAYTRAIL +#if IS_ENABLED(CONFIG_SND_SOC_SOF_BAYTRAIL) static void byt_reset_dsp_disable_int(struct snd_sof_dev *sdev) { /* Disable Interrupt from both sides */ -- 2.29.2

2 7