From: Liam Girdwood <lrg@ti.com>
To: Sebastien LEDUC <sebastien.leduc@st.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
Mark Brown <broonie@opensource.wolfsonmicro.com>
Subject: Re: dynamic PCM and dynamic DSP graphs
Date: Fri, 19 Oct 2012 11:51:41 +0100 [thread overview]
Message-ID: <508130BD.4060909@ti.com> (raw)
In-Reply-To: <9C1683ABA24673439FCD019782C9F4BBDA29EC8998@SAFEX1MAIL1.st.com>
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
>
next prev parent reply other threads:[~2012-10-19 10:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-19 9:39 dynamic PCM and dynamic DSP graphs Sebastien LEDUC
2012-10-19 10:51 ` Liam Girdwood [this message]
2012-10-19 11:56 ` Sebastien LEDUC
2012-10-19 14:36 ` Liam Girdwood
2012-10-22 12:04 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=508130BD.4060909@ti.com \
--to=lrg@ti.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=sebastien.leduc@st.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.