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