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@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??