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

[Sound-open-firmware] question: status sound on Intel NUC M15
by Gilles van Eeden 12 Jul '21

12 Jul '21

Hi, hopefully this is the right place for this question. I've fruitlessly been trying to get sound to work on the Intel NUC M15 <https://linux-hardware.org/?probe=93690f8eec>. A fitting topology for this platform seems lacking, among other things. Is there any work ongoing on this? I will gladly provide diagnostic data from my system, if so desired. Best regards, Gilles

2 1

[Sound-open-firmware] [PATCH AUTOSEL 5.13 025/114] ASoC: SOF: topology: fix assignment to use le32_to_cpu
by Sasha Levin 10 Jul '21

10 Jul '21

From: Jaska Uimonen <jaska.uimonen(a)linux.intel.com> [ Upstream commit ccaea61a8d1b8180cc3c470e383381884e4bc1f2 ] Fix sparse warning by using le32_to_cpu. Signed-off-by: Jaska Uimonen <jaska.uimonen(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> Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Link: https://lore.kernel.org/r/20210521092804.3721324-6-kai.vehmanen@linux.intel… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c index 59abcfc9bd55..cb16b2bd8c21 100644 --- a/sound/soc/sof/topology.c +++ b/sound/soc/sof/topology.c @@ -3335,7 +3335,7 @@ static int sof_link_load(struct snd_soc_component *scomp, int index, /* Copy common data to all config ipc structs */ for (i = 0; i < num_conf; i++) { config[i].hdr.cmd = SOF_IPC_GLB_DAI_MSG | SOF_IPC_DAI_CONFIG; - config[i].format = hw_config[i].fmt; + config[i].format = le32_to_cpu(hw_config[i].fmt); config[i].type = common_config.type; config[i].dai_index = common_config.dai_index; } -- 2.30.2

1 0

[Sound-open-firmware] Query regarding Sound Open Firmware
by Srivally Munnangi 24 Jun '21

24 Jun '21

Hi Team Myself Srivally, from Hyderabad, India. I have recently come across sound open firmware . I have a query regarding the same. Can you please let me know whether SOF can be installed on Windows PCs? Thanks Srivally

1 0

Re: [Sound-open-firmware] [PATCH] ASoC: SOF: Intel: Remove duplicate include of shim.h
by Ranjani Sridharan 03 Jun '21

03 Jun '21

On Thu, 2021-06-03 at 10:59 +0800, Wan Jiabing wrote: > shim.h is included twice. > As shim.h is not related to later header file, > keep one which has comment and remove the former one. > > Signed-off-by: Wan Jiabing <wanjiabing(a)vivo.com> > --- > sound/soc/sof/intel/pci-tng.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/sound/soc/sof/intel/pci-tng.c b/sound/soc/sof/intel/pci- > tng.c > index 4ee1da3..4bded66 100644 > --- a/sound/soc/sof/intel/pci-tng.c > +++ b/sound/soc/sof/intel/pci-tng.c > @@ -15,7 +15,6 @@ > #include <sound/sof.h> > #include "../ops.h" > #include "atom.h" > -#include "shim.h" > #include "../sof-pci-dev.h" > #include "../sof-audio.h" > Thanks for the patch. Reviewed-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com>

1 0

[Sound-open-firmware] Commit c80270e7e49 (" ipc: structures should all be aligned on 4 bytes") causes issues on i.MX8
by Daniel Baluta 11 May '21

11 May '21

Hi Liam, I noticed this SOF commit: commit c80270e7e49d26a34fe284d1868e7d9cb80104f1 Author: Liam Girdwood <liam.r.girdwood(a)linux.intel.com> Date: Sat Apr 3 21:22:21 2021 +0100 ipc: structures should all be aligned on 4 bytes Give the compiler a chance to further optimise IPC data access since it's all on a 4 byte alignment. Signed-off-by: Liam Girdwood <liam.r.girdwood(a)linux.intel.com> It looks like it triggers some issues on i.MX8. Is there any equivalent for Linux kernel? Some structures are shared with the kernel and on arm64 it assumes default alignment as 8 hence I get a mismatch at least when printing DAI / Host position + dev_info(sdev->dev, "posn : host 0x%llx dai 0x%llx wall 0x%llx no_per %d\n", + posn.host_posn, posn.dai_posn, posn.wallclock, stream->substream->runtime->no_period_wakeup); thanks, Daniel.

3 4

[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