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

[Sound-open-firmware] [ANNOUNCE] SOF v1.7 released
by Girdwood, Liam R 06 Apr '21

06 Apr '21

The SOF developers are pleased to announce that version 1.7 has been released and binaries available for Intel and NXP platforms[1]. The main focus of v1.7 was around adding support for new audio processing algorithms, continued Zephyr integration and general stabilisation. Release notes are here. https://github.com/thesofproject/sof/releases/tag/v1.7 Binaries are here. https://github.com/thesofproject/sof-bin Firmware issues can be reported here (and feature requests too). https://github.com/thesofproject/sof/issues and kernel issues here https://github.com/thesofproject/linux/issues The next version will be v1.8 due by the end of June. Thanks Liam [1] Preliminary support for other platforms can be enabled by using SOF as a Zephyr module (for Zephyr supported architectures and platforms). --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 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.

2 1

[Sound-open-firmware] crosstool-ng branch sof-gcc8.1
by Daniel Baluta 02 Apr '21

02 Apr '21

Hi Liam, sof-gcc8.1 branch of crosstool-ng fails to build a cross compiler (i think for all platforms) because expat version 2.2.5 ( CT_EXPAT_VERSION="2.2.5" ) is vulnerable. https://sourceforge.net/projects/expat/files/expat/2.2.5/expat-2.2.5-RENAME… What's your take on this? Should we change the config files to upgrade expat to 2.3.0 or should we directly use newer versions of gcc. What gcc toolchain versions is Intel using? We at NXP want to align with that. thanks, Daniel.

2 1

[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