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

[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