[alsa-devel] dynamic PCM and dynamic DSP graphs
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
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:
Runtime DAPM graph update was a topic brought up at the recent plumbers conference in San Diego.......
Will this not race against the graph walk ? as it sounds like you are changing the graph during the DAPM walk here.
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
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
On 19/10/12 12:56, Sebastien LEDUC wrote:
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
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.
participants (3)
-
Liam Girdwood
-
Mark Brown
-
Sebastien LEDUC