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

[Liam Girdwood]

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:
> > On Wed, 2012-01-25 at 17:07 +0000, Liam Girdwood wrote:
> >> We could eventually remove steps 2 and 4 for the FE DAI link, and look
> >> at hard coding the hw_params() in the mach driver for the loopback
> >> link.
> >> That way the only user space driven actions would be to configure the
> >> mixers in the CODEC and DSP for the correct route. DAPM would then
> >> detect the path and Dynamic PCM would use the hard coded configuration
> >> or bespoke mach driver logic to configure the loopback DAI link based
> >> on
> >> use case. This would have to be done after the basic Dynamic PCM
> >> infrastructure was upstream though (unless you have a patch atm).
> > Hi,
> > Sorry to join the party late :-)
> >
> 

No worries ;-)

> 
> > 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.

Regards

Liam

> >
> > --
> > ~Vinod
> >
>