On Fri, Jun 15, 2018 at 9:28 PM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:

On Fri, 2018-06-15 at 18:42 +0300, Daniel Baluta wrote:

...

Hi,

Does SOF firmware/driver supports loading a library and executing code from it?

Yes, this can currently done by :-

1. Building the library (source or binary) into the base firmware image like

SRC, mixer etc is today.

2. Building the library as a separate module that is stitched into the FW image

and loaded with base FW (like boot loader on APL/CNL).

and step 3 is work in progress (in module branch)

3. Building the library as a separate module that is loaded and linked at

runtime (like Linux kernel modules).

Thanks Liam, I was looking for 3)

Daniel.

On 6/20/18 9:52 AM, Daniel Baluta wrote:

On Fri, Jun 15, 2018 at 9:28 PM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:

...

On Fri, 2018-06-15 at 18:42 +0300, Daniel Baluta wrote:

...

Hi,

Does SOF firmware/driver supports loading a library and executing code from it?

Yes, this can currently done by :-

1. Building the library (source or binary) into the base firmware image like

SRC, mixer etc is today.

2. Building the library as a separate module that is stitched into the FW image

and loaded with base FW (like boot loader on APL/CNL).

and step 3 is work in progress (in module branch)

3. Building the library as a separate module that is loaded and linked at

runtime (like Linux kernel modules).

Thanks Liam. Another question:

After implementing 3) how one can use the DSP to decode for example an mp3 file back into a pcm file.

I have some libraries that DSP can use to decode mp3 into pcm.

So, I assume I can use cplay to stream an mp3 file into a compress device then create a pipeline of components and buffers, but i'm not sure how do I get the pcm decoded bytes back. Ideally, would be to use crecord.

So you want the PCM samples to be provided back to userspace?

That's not really a configuration we've tested at Intel, and the compressed stuff was more geared towards direct connection to the hardware to save on power.

It's still possible but you have to play with the topology and have one stream providing the compressed data and another one to record, with some special scheduling to make sure this activity doesn't prevent the DSP from working (there is no output DMA or timer event to throttle the processing and e.g. handle IPC)

I'm still reading sof code. Any ideas would be great!

thanks, daniel. _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware

On Fri, Jun 15, 2018 at 9:28 PM, Liam Girdwood liam.r.girdwood@linux.intel.com wrote:

On Fri, 2018-06-15 at 18:42 +0300, Daniel Baluta wrote:

...

Hi,

Does SOF firmware/driver supports loading a library and executing code from it?

Yes, this can currently done by :-

1. Building the library (source or binary) into the base firmware image like

SRC, mixer etc is today.

2. Building the library as a separate module that is stitched into the FW image

and loaded with base FW (like boot loader on APL/CNL).

and step 3 is work in progress (in module branch)

3. Building the library as a separate module that is loaded and linked at

runtime (like Linux kernel modules).

Hi Liam,

Just wanted to check with you if I'm going in the correct direction.

I'm trying to play an mp3 file using cplay from tinycompres. The question now is when to load the codec library.

It seems that the codec_id can be passed via SNDRV_COMPRESS_SET_PARAMS stored inside snd_codec id field.

Now, I can load the codec library in stream->ops->set_params and since set_params is called in compress_open I can have the codec loaded before playing starts.

My concern is that I also need to unload the library (to free resources) when playing is done.

But, there is no symmetric call to set_params to be called in compress_close.

Any idea is welcomed.

thanks, Daniel.

On 6/27/18 12:49 AM, Liam Girdwood wrote:

On Tue, 2018-06-26 at 19:05 +0300, Daniel Baluta wrote:

...

Just wanted to check with you if I'm going in the correct direction.

I'm trying to play an mp3 file using cplay from tinycompres. The question now is when to load the codec library.

It seems that the codec_id can be passed via SNDRV_COMPRESS_SET_PARAMS stored inside snd_codec id field.

Now, I can load the codec library in stream->ops->set_params and since set_params is called in compress_open I can have the codec loaded before playing starts.

My concern is that I also need to unload the library (to free resources) when playing is done.

But, there is no symmetric call to set_params to be called in compress_close.

No sure, Pierre did a lot on work on the compressed APIs so best for him to comment on the intended approach here.

If nothing is obvious, perhaps we need to add an equivalent of hw_free() for compressed streams.

The compressed API dates from maybe 2011 and at the time the firmware contained all the relevant libraries. The SET_PARAMS was just a selector of the right mode (provided with the snd_codec structure), not really something that would allocate resources or download modules on the fly. If we use this API in conjunction with firmware modules then an update may be needed. Clearly that wasn't something we thought about.