dynamic PCM and dynamic DSP graphs

dynamic PCM and dynamic DSP graphs

[Sebastien LEDUC]

Hi Mark / Liam,
We have started to use Dynamic PCM to manage our on-SoC DSP.
In our case, the API exposed by the DSP is graph oriented, and allows to dynamically create and control the running graph on the DSP.

What we are doing is that we use DAPM widgets and routes to manage  the DSP graph dynamically:
We use some dedicated widgets that have power callbacks. 
When a  widget is powered on/off, the callback will use the DSP API to create/destroy the corresponding parts of the DSP graph.

We wanted to get your feedback on this approach, so as to be sure it won't be an issue when we want to mainline our driver.
We can of course share more details if needed, or even some preliminary version of the driver.

Thanks in advance for your feedback

Regards
Sebastien

 
 

Re: dynamic PCM and dynamic DSP graphs

[Liam Girdwood]

Hi Sebastien,

Best to always CC Mark and I if you want a quicker reply from either of us.

On 19/10/12 10:39, Sebastien LEDUC wrote:
> Hi Mark / Liam,
> We have started to use Dynamic PCM to manage our on-SoC DSP.
> In our case, the API exposed by the DSP is graph oriented, and allows to dynamically create and control the running graph on the DSP.

Runtime DAPM graph update was a topic brought up at the recent plumbers conference in San Diego.......

> What we are doing is that we use DAPM widgets and routes to manage  the DSP graph dynamically:
> We use some dedicated widgets that have power callbacks. 
> When a  widget is powered on/off, the callback will use the DSP API to create/destroy the corresponding parts of the DSP graph.

Will this not race against the graph walk ? as it sounds like you are changing the graph during the DAPM walk here.

> We wanted to get your feedback on this approach, so as to be sure it won't be an issue when we want to mainline our driver.
> We can of course share more details if needed, or even some preliminary version of the driver.
> 
> Thanks in advance for your feedback

I think the consensus reached at plumbers was that we would use the media framework API to export the graph information to userspace and also allow userspace to change the graph objects and routing (via media framework APIs). The media framework guys were happy to support this albeit the media framework is missing some functionality to remove graph objects atm (iirc it can currently add and change graph objects).

It was agreed at plumbers that I would add graph removal support to the media framework but I still have to complete the upstream of firmware graph/mixer support and the OMAP4 ABE first (another 3 months). Please do feel free to add this support if you need it quicker.

Does this sound like it would fit with your driver use case for graph updates ? It certainly seemed to fit in with the other HW vendors at plumbers with similar architectures.

Regards

Liam

> 
> Regards
> Sebastien
> 
>  
>  
> 
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 

Re: dynamic PCM and dynamic DSP graphs

[Sebastien LEDUC]

Hi Liam,
Thank for the quick reply

> Will this not race against the graph walk ? as it sounds like you are changing the graph during the DAPM walk here.

No, we are not changing the DAPM graph during the graph walk.
We are only changing the DSP graph

> I think the consensus reached at plumbers was that we would use the media framework API to export the graph information to userspace and also allow userspace to change the graph objects and routing (via media framework APIs). The media framework guys were > happy to support this albeit the media framework is missing some functionality to remove graph objects atm (iirc it can currently add and change graph objects).

How will this interact with the DSP DAPM graph?

Regards,
Sebastien

Re: dynamic PCM and dynamic DSP graphs

[Liam Girdwood]

On 19/10/12 12:56, Sebastien LEDUC wrote:
> 
> Hi Liam,
> Thank for the quick reply
> 
>> Will this not race against the graph walk ? as it sounds like you are changing the graph during the DAPM walk here.
> 
> No, we are not changing the DAPM graph during the graph walk.
> We are only changing the DSP graph
> 
>> I think the consensus reached at plumbers was that we would use the media framework API to export the graph information to userspace and also allow userspace to change the graph objects and routing (via media framework APIs). The media framework guys were > happy to support this albeit the media framework is missing some functionality to remove graph objects atm (iirc it can currently add and change graph objects).
> 
> How will this interact with the DSP DAPM graph?
> 

I've not looked into the mechanics of the media interface DAPM integration yet, but we will just use media frameworks existing APIs to visualize and modify the card DAPM graph in userspace (we can also visualize some attributes for paths and widgets too).

The intention is for userspace to create/destroy/modify the DAPM DSP graph per use case. i.e. we would be able to add/rm new widgets and paths depending on use case transitions which could be: to improve DSP performance, lower DSP power, to fit within DSP resourcing constraints. e.g. we could remove a DAPM mixer widget from the output DSP DAPM path to conserve DSP power and memory for other tasks. 

Regards

Liam

Re: dynamic PCM and dynamic DSP graphs

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 339 bytes --]

On Fri, Oct 19, 2012 at 11:51:41AM +0100, Liam Girdwood wrote:

> Best to always CC Mark and I if you want a quicker reply from either of us.

Just to emphasise this point - for *all* Linux kernel things you should
always CC maintainers on mails.  Things sent to the list only are liable
to get lost.  It's not something specific to ASoC.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]