Re: soc-dsp programming model for loopbacks

Re: soc-dsp programming model for loopbacks

[Mark Brown]

On Tue, Jan 24, 2012 at 01:36:18PM -0800, Pierre-Louis Bossart wrote:

> Now if the FM radio routing is handled with a digital loopback on the
> application processor audio dsp (omap-abe, Intel SST, etc), then soc-dsp
> will need to be used. And for a simple FM playback, I need to 

Note that the use of soc-dsp isn't required for on-SoC DSPs - it really
depends on how the hardware looks.  If the DSP external format is very
strongly tied to the format used to DMA to and from main memory (or
other interfaces) then soc-dsp is what you need, if the DSP is able to
rewrite formats more flexibly then it should be more direct to model it
as a CODEC device with whatever number of DAIs and routing between them.

Re: soc-dsp programming model for loopbacks

[Liam Girdwood]

On Tue, 2012-01-24 at 22:00 +0000, Mark Brown wrote:
> On Tue, Jan 24, 2012 at 01:36:18PM -0800, Pierre-Louis Bossart wrote:
> 
> > Now if the FM radio routing is handled with a digital loopback on the
> > application processor audio dsp (omap-abe, Intel SST, etc), then soc-dsp
> > will need to be used. And for a simple FM playback, I need to 
> 
> Note that the use of soc-dsp isn't required for on-SoC DSPs - it really
> depends on how the hardware looks.  If the DSP external format is very
> strongly tied to the format used to DMA to and from main memory (or
> other interfaces) then soc-dsp is what you need, if the DSP is able to
> rewrite formats more flexibly then it should be more direct to model it
> as a CODEC device with whatever number of DAIs and routing between them.

It's also needed if your DSP cant control or configure any of your host
CPU DAI hardware controllers that it needs to physically use to route
audio data.

Regards

Liam

Re: soc-dsp programming model for loopbacks

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 973 bytes --]

On Wed, Jan 25, 2012 at 05:12:25PM +0000, Liam Girdwood wrote:
> On Tue, 2012-01-24 at 22:00 +0000, Mark Brown wrote:

> > Note that the use of soc-dsp isn't required for on-SoC DSPs - it really
> > depends on how the hardware looks.  If the DSP external format is very
> > strongly tied to the format used to DMA to and from main memory (or
> > other interfaces) then soc-dsp is what you need, if the DSP is able to
> > rewrite formats more flexibly then it should be more direct to model it
> > as a CODEC device with whatever number of DAIs and routing between them.

> It's also needed if your DSP cant control or configure any of your host
> CPU DAI hardware controllers that it needs to physically use to route
> audio data.

Depends how they're allocated - the DSP driver can always do the
management on behalf of the DSP firmware if the hardware is structured
in a way that makes that make sense (for example, if the CPU never talks
to the outside world directly).

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: soc-dsp programming model for loopbacks

[Liam Girdwood]

On Wed, 2012-01-25 at 17:20 +0000, Mark Brown wrote:
> On Wed, Jan 25, 2012 at 05:12:25PM +0000, Liam Girdwood wrote:
> > On Tue, 2012-01-24 at 22:00 +0000, Mark Brown wrote:
> 
> > > Note that the use of soc-dsp isn't required for on-SoC DSPs - it really
> > > depends on how the hardware looks.  If the DSP external format is very
> > > strongly tied to the format used to DMA to and from main memory (or
> > > other interfaces) then soc-dsp is what you need, if the DSP is able to
> > > rewrite formats more flexibly then it should be more direct to model it
> > > as a CODEC device with whatever number of DAIs and routing between them.
> 
> > It's also needed if your DSP cant control or configure any of your host
> > CPU DAI hardware controllers that it needs to physically use to route
> > audio data.
> 
> Depends how they're allocated - the DSP driver can always do the
> management on behalf of the DSP firmware if the hardware is structured
> in a way that makes that make sense (for example, if the CPU never talks
> to the outside world directly).

Wouldn't that either mean the DSP driver (re)implements some of the CPU
DAI driver operations OR the DSP driver calling the CPU DAI driver ops
directly ? 

Regards

Liam

Re: soc-dsp programming model for loopbacks

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 935 bytes --]

On Wed, Jan 25, 2012 at 05:48:57PM +0000, Liam Girdwood wrote:
> On Wed, 2012-01-25 at 17:20 +0000, Mark Brown wrote:

> > Depends how they're allocated - the DSP driver can always do the
> > management on behalf of the DSP firmware if the hardware is structured
> > in a way that makes that make sense (for example, if the CPU never talks
> > to the outside world directly).

> Wouldn't that either mean the DSP driver (re)implements some of the CPU
> DAI driver operations OR the DSP driver calling the CPU DAI driver ops
> directly ? 

Like I say it depends on how the hardware is structured - the cases I
was thinking about in the example above were those where the CPU needs
to push everything through the DSP (or other in-SoC IP block, some have
other interesting hardware in the way) so the DAI driver the CPU itself
ends up with is different to and probably much simpler than that for the
external interface.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: soc-dsp programming model for loopbacks

[Liam Girdwood]

On Tue, 2012-01-24 at 13:36 -0800, Pierre-Louis Bossart wrote:
> Hi,
> I've been doing some work on audio loopback (FM radio, BT, Modem -> audio
> codec), and I am somewhat confused by the soc-dsp programming model. Let me
> take the FM radio example:
> 
> If the FM radio is directly connected to the audio codec, my understanding
> is that changing the routing with codec controls will trigger the DAPM
> logic, which will turn on everything that needs to be on. Very simple, no
> matter if the FM-codec link is analog or digital.
> 

Yep, this is correct. soc-dsp (now know as Dynamic PCM) takes care of
any digital links that require the host CPU to perform any PCM or DAI
operations (based again on DAPM graph status). i.e. on OMAP we can start
the McBSP to FM Digital DAI based on the DAPM graph status and then
configure the link format, speed etc to optimal values for the ABE and
FM. 

It's not required for the analog path as DAPM will switch on the correct
components for FM analog to be played on the CODEC Speaker output.

> Now if the FM radio routing is handled with a digital loopback on the
> application processor audio dsp (omap-abe, Intel SST, etc), then soc-dsp
> will need to be used. And for a simple FM playback, I need to 
> 1. configure the audio codec routing for output selection 
> 2. open a virtual front-end for FM capture 
> 3. configure the DSP routing to link capture front-end to I2S1 backend (FM
> interface) 
> 4. open a virtual front-end for FM playback 
> 5. configure the DSP routing to link playback front-end to I2S2 backend
> (codec interface)
> 

Using Dynamic PCM here really depends on your hardware capabilities. On
OMAP, the host CPU configures and manages all DAIs so Dynamic PCM
manages the DAI and PCM operations. We also have the need to re-write
the hw_params and DAI formats between the FEs and BEs for optimum
performance.

> That seems complicated. To some extent, having the ability to have two
> back-ends connected together would make more sense, and would simplify the
> programming model a great deal. User-space code would be similar for
> loopbacks internal to the codecs or handled on the application processor.
> This would apply to Bluetooth and modem connections as well. Without this
> capability, we will end-up with multiple 'virtual' front-ends (6 in my
> case), making user-space code quite complex.

It's not really that much extra code, it's really just open(),
hw_params() and pcm_start() on the FE. Steps 1,3 & 5 are compulsory
anyway for any audio device, but we need to configure format, rate, DAI
clocking for the loopback. Having the FE PCM gives us this capability,
although we dont transfer any data to or from the host with the FE so
it's use is only for configuration.

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

> Looking at the current soc-dsp code, I saw that each back-end is supposed to
> have at least one front-end client, and the impact of my proposal seems
> fairly important. Before I start looking further into code changes, I wanted
> to see if my understanding is correct and if there are other ideas to
> simplify loopbacks.

Atm with the current code base we can support routing many FE PCMs to
many BE PCMs. We can support the BE loopback, but this does require the
FE to be opened atm in order to configure the DAI link. 

Regards

Liam

Re: soc-dsp programming model for loopbacks

[Mark Brown]

On Wed, Jan 25, 2012 at 05:07:29PM +0000, Liam Girdwood wrote:
> On Tue, 2012-01-24 at 13:36 -0800, Pierre-Louis Bossart 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's what the CODEC<->CODEC stuff is all about, hiding the link from
userspace.

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

I've sort of got one, tidying it up and pushing it out keeps on being
very near the top of my list but I've never actually got it looking nice
enough for me to actually want to send it out.

Re: soc-dsp programming model for loopbacks

[Liam Girdwood]

On Wed, 2012-01-25 at 17:11 +0000, Mark Brown wrote:
> On Wed, Jan 25, 2012 at 05:07:29PM +0000, Liam Girdwood wrote:
> > On Tue, 2012-01-24 at 13:36 -0800, Pierre-Louis Bossart 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's what the CODEC<->CODEC stuff is all about, hiding the link from
> userspace.
> 

Ok, cool - Is the formatting and params hard coded ?

Liam

Re: soc-dsp programming model for loopbacks

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 616 bytes --]

On Wed, Jan 25, 2012 at 05:13:07PM +0000, Liam Girdwood wrote:
> On Wed, 2012-01-25 at 17:11 +0000, Mark Brown wrote:

> > That's what the CODEC<->CODEC stuff is all about, hiding the link from
> > userspace.

> Ok, cool - Is the formatting and params hard coded ?

My implementations thus far have been able to infer these from the
capabilities of the devices they're connecting (one end of the link is
usually a device with a fixed configuration) and therefore not needed to
worry about this.  However this has always been the most painful bit of
the code so I'm probably going to make it hard coded or something.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: soc-dsp programming model for loopbacks

[Pierre-Louis Bossart]

> That's what the CODEC<->CODEC stuff is all about, hiding the link from
> userspace.

I can see how this would simplify the loopback part, but doesn't it make the
'regular' playback/capture functionality more complex? If my DSP is seen as
a CODEC, how do I represent the CPU-DSP interface (DMA or shared memory)?

Re: soc-dsp programming model for loopbacks

[Mark Brown]

On Wed, Jan 25, 2012 at 12:03:42PM -0800, Pierre-Louis Bossart wrote:
> > That's what the CODEC<->CODEC stuff is all about, hiding the link from
> > userspace.

> I can see how this would simplify the loopback part, but doesn't it make the
> 'regular' playback/capture functionality more complex? If my DSP is seen as
> a CODEC, how do I represent the CPU-DSP interface (DMA or shared memory)?

You'd need a DAI for that interface but you'll need that no matter what
you do, it'll just be a very simple DAI that needs no configuration for
things like AIF format.  With the soc-pcm setup you also need the front
and back end DAIs so it's about the same, the benefit comes at runtime.
My primary focus for the CODEC<->CODEC links is actually things like
basebands rather than on-SoC DSPs, it's just that if the hardware can be
thought of in the same way it should simplify things a little.

Re: soc-dsp programming model for loopbacks

[Pierre-Louis Bossart]

>> I can see how this would simplify the loopback part, but doesn't it make the
>> 'regular' playback/capture functionality more complex? If my DSP is seen as
>> a CODEC, how do I represent the CPU-DSP interface (DMA or shared memory)?
>
> You'd need a DAI for that interface but you'll need that no matter what
> you do, it'll just be a very simple DAI that needs no configuration for
> things like AIF format.  With the soc-pcm setup you also need the front
> and back end DAIs so it's about the same, the benefit comes at runtime.
> My primary focus for the CODEC<->CODEC links is actually things like
> basebands rather than on-SoC DSPs, it's just that if the hardware can be
> thought of in the same way it should simplify things a little.

Bear with me here, I am still somewhat confused.
- Liam suggested either a hard-coded DAI configuration or machine driver 
logic to remove the need for virtual front-ends
- Mark suggested to consider the DSP as a CODEC with some work to 
re-implement the host-dsp interface.
Is this CODEC<->CODEC solution on top of the Dynamic PCM patches? Or are 
we talking about two completely different approaches?
Thanks for your feedback
-Pierre

Re: soc-dsp programming model for loopbacks

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 948 bytes --]

On Thu, Jan 26, 2012 at 07:12:07AM -0600, Pierre-Louis Bossart wrote:

> Bear with me here, I am still somewhat confused.
> - Liam suggested either a hard-coded DAI configuration or machine
> driver logic to remove the need for virtual front-ends
> - Mark suggested to consider the DSP as a CODEC with some work to
> re-implement the host-dsp interface.
> Is this CODEC<->CODEC solution on top of the Dynamic PCM patches? Or
> are we talking about two completely different approaches?

The two are orthogonal to each other but complimenary.  Like I say it
really depends on how your hardware is wired up - it depends on the
level of isolation that the DSP provides between the CPU and the outside
world.

If the system looks like:

    CPU <-> DSP <-> External

you should model the DSP as a separate device.  If on the other hand it
looks more like this:


   DSP     External
    ^----v----^
        CPU

then soc-pcm is what you're looking for.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: soc-dsp programming model for loopbacks

[Liam Girdwood]

On Thu, 2012-01-26 at 14:03 +0000, Mark Brown wrote:
> On Thu, Jan 26, 2012 at 07:12:07AM -0600, Pierre-Louis Bossart wrote:
> 
> > Bear with me here, I am still somewhat confused.
> > - Liam suggested either a hard-coded DAI configuration or machine
> > driver logic to remove the need for virtual front-ends
> > - Mark suggested to consider the DSP as a CODEC with some work to
> > re-implement the host-dsp interface.
> > Is this CODEC<->CODEC solution on top of the Dynamic PCM patches? Or
> > are we talking about two completely different approaches?
> 
> The two are orthogonal to each other but complimenary.  Like I say it
> really depends on how your hardware is wired up - it depends on the
> level of isolation that the DSP provides between the CPU and the outside
> world.
> 
> If the system looks like:
> 
>     CPU <-> DSP <-> External
> 
> you should model the DSP as a separate device.  If on the other hand it
> looks more like this:
> 
> 
>    DSP     External
>     ^----v----^
>         CPU
> 
> then soc-pcm is what you're looking for.

Fwiw, the OMAP ABE architecture mixes both above diagrams. We are using
dynamic PCM for managing all the DAI links and will add in support to
use the CODEC <-> CODEC stuff for the loopback DAI interfaces (saving
the need to open()), hw_oparams() etc).

Regards

Liam

Re: soc-dsp programming model for loopbacks

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 642 bytes --]

On Thu, Jan 26, 2012 at 02:27:48PM +0000, Liam Girdwood wrote:
> On Thu, 2012-01-26 at 14:03 +0000, Mark Brown wrote:

> >     CPU <-> DSP <-> External

> >    DSP     External
> >     ^----v----^
> >         CPU

> Fwiw, the OMAP ABE architecture mixes both above diagrams. We are using
> dynamic PCM for managing all the DAI links and will add in support to
> use the CODEC <-> CODEC stuff for the loopback DAI interfaces (saving
> the need to open()), hw_oparams() etc).

In terms of the data path I think it's pretty much always like the
second path with the DMA controller owned by Linux driving the data
between the various components?

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: soc-dsp programming model for loopbacks

[Liam Girdwood]

On Thu, 2012-01-26 at 14:32 +0000, Mark Brown wrote:
> On Thu, Jan 26, 2012 at 02:27:48PM +0000, Liam Girdwood wrote:
> > On Thu, 2012-01-26 at 14:03 +0000, Mark Brown wrote:
> 
> > >     CPU <-> DSP <-> External
> 
> > >    DSP     External
> > >     ^----v----^
> > >         CPU
> 
> > Fwiw, the OMAP ABE architecture mixes both above diagrams. We are using
> > dynamic PCM for managing all the DAI links and will add in support to
> > use the CODEC <-> CODEC stuff for the loopback DAI interfaces (saving
> > the need to open()), hw_oparams() etc).
> 
> In terms of the data path I think it's pretty much always like the
> second path with the DMA controller owned by Linux driving the data
> between the various components?

Wrt OMAP, the DMA and the ABE can drive data to the component drivers.
Both DMA and ABE only drive data at the request of the CPU (via PCM and
DAI ops).

Regards

Liam 

Re: soc-dsp programming model for loopbacks

[Vinod Koul]

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 :-)

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.

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 :)

-- 
~Vinod

Re: 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@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
> >
> 

Re: soc-dsp programming model for loopbacks

[Vinod Koul]

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

-- 
~Vinod

Re: soc-dsp programming model for loopbacks

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 443 bytes --]

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: soc-dsp programming model for loopbacks

[Vinod Koul]

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?

-- 
~Vinod

Re: soc-dsp programming model for loopbacks

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 388 bytes --]

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: soc-dsp programming model for loopbacks

[Liam Girdwood]

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

soc-dsp programming model for loopbacks

[Pierre-Louis Bossart]

Hi,
I've been doing some work on audio loopback (FM radio, BT, Modem -> audio
codec), and I am somewhat confused by the soc-dsp programming model. Let me
take the FM radio example:

If the FM radio is directly connected to the audio codec, my understanding
is that changing the routing with codec controls will trigger the DAPM
logic, which will turn on everything that needs to be on. Very simple, no
matter if the FM-codec link is analog or digital.

Now if the FM radio routing is handled with a digital loopback on the
application processor audio dsp (omap-abe, Intel SST, etc), then soc-dsp
will need to be used. And for a simple FM playback, I need to 
1. configure the audio codec routing for output selection 
2. open a virtual front-end for FM capture 
3. configure the DSP routing to link capture front-end to I2S1 backend (FM
interface) 
4. open a virtual front-end for FM playback 
5. configure the DSP routing to link playback front-end to I2S2 backend
(codec interface)

That seems complicated. To some extent, having the ability to have two
back-ends connected together would make more sense, and would simplify the
programming model a great deal. User-space code would be similar for
loopbacks internal to the codecs or handled on the application processor.
This would apply to Bluetooth and modem connections as well. Without this
capability, we will end-up with multiple 'virtual' front-ends (6 in my
case), making user-space code quite complex.
Looking at the current soc-dsp code, I saw that each back-end is supposed to
have at least one front-end client, and the impact of my proposal seems
fairly important. Before I start looking further into code changes, I wanted
to see if my understanding is correct and if there are other ideas to
simplify loopbacks.
Thanks for your feedback,
-Pierre