[alsa-devel] soc-dsp programming model for loopbacks

Vinod Koul vinod.koul at linux.intel.com
Thu Feb 2 13:03:20 CET 2012


On Thu, 2012-02-02 at 11:17 +0000, Liam Girdwood wrote:
> On Wed, 2012-02-01 at 11:50 +0000, Girdwood, Liam wrote:
> > On 1 February 2012 09:07, Vinod Koul <vinod.koul at linux.intel.com> wrote
> > 
> > > Liam, if we configure the hw_params in the machine driver statically,
> > > represent the DSP using a map along with a codec kind of modeling.
> > >
> 
> In OMAP we reconfigure (or fixup) some of the hw_params() in the machine
> driver for a BE DAI link that cant operate at the requested FE params.
> The ABE takes care of any conversion though. 

> 
> > > Would the BEs be triggered on from soc_dsp_runtime_update() when the
> > > loopback is established thru the DSP.
> > > This way we avoid all the "virtual" FEs. Use loopback to turn on codec
> > > and DSP (thru BEs)
> > >
> > > Would this make sense, or I need more coffee :)
> In the code base atm we have to use a FE pcm to trigger the BE loopback
> DAIs. however, the intention is to use Mark's CODEC <-> CODEC DAI link
> work to support the loopback with hard coded params in the machine
> driver. This would save the need for any FE pcm operations.
precisely my thoughts :)
Assuming we dont have to worry about hw_params (hard coded in machine),
then establishing a loopback with two BEs should automatically trigger
DAPM to detect a loopback, and by principle start these BEs and any
associated codec DAIs. Does this idea sound good?

Now to actual changes, when will we see dynamic-pcm in asoc-next :-)

And Mark, can we see your wip changes??

-- 
~Vinod



More information about the Alsa-devel mailing list