Re: [alsa-devel] soc-dsp programming model for loopbacks
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:
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
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??
On Thu, Feb 02, 2012 at 05:33:20PM +0530, Vinod Koul wrote:
And Mark, can we see your wip changes??
No. I essentially never have any WIP changes, anything I do to the point where it's actually useful gets submitted to mainline pretty much immediately. I did do some stuff but it was too horrible as it was trying to figure out the hw_params automatically and this was causing appauling pain, underlying changes have bitrotted that away.
On Thu, 2012-02-02 at 12:06 +0000, Mark Brown wrote:
On Thu, Feb 02, 2012 at 05:33:20PM +0530, Vinod Koul wrote:
And Mark, can we see your wip changes??
No. I essentially never have any WIP changes, anything I do to the point where it's actually useful gets submitted to mainline pretty much immediately. I did do some stuff but it was too horrible as it was trying to figure out the hw_params automatically and this was causing appauling pain, underlying changes have bitrotted that away.
Okay thanks.
your thoughts on how this should be done?
On Thu, Feb 02, 2012 at 05:48:21PM +0530, Vinod Koul wrote:
your thoughts on how this should be done?
Well, the most pressing things are to do something about the hard coded` codec_dai/cpu_dai in the rtd structure, and to make the mechanism for starting up streams a bit more integrated with the rest of the world. Once those are in place it should be a simple matter of programming.
On Thu, 2012-02-02 at 17:33 +0530, Vinod Koul wrote:
Now to actual changes, when will we see dynamic-pcm in asoc-next :-)
My apologies, customer work has been getting priority over upstreaming for me in the last 6 months or so. We should see another batch of patches next week.
Liam
participants (3)
-
Liam Girdwood -
Mark Brown -
Vinod Koul