Re: [alsa-devel] Question about your DSP topic branch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/15/2011 4:25 AM, Mark Brown wrote:
On Tue, Mar 15, 2011 at 12:08:39AM -0700, Patrick Lai wrote:

1. If there are two front-ends routed to same backend, which front-end
hardware parameters should backend DAI be based on? For example, one
front-end is MONO and another front is stereo.

2. Depending on device mode/use case, I would like to configure BE to
different channel mode irrespective of front-end configuration(i.e
configuring back-end to handset mode). Where is the hook to do so under
ASoC DSP framework?

If you can configure the two completely separately then you can just
have a DAPM path between the two devices and don't need to link the DAI
configurations at all - WM8994 is an example of doing this, there is a
bunch of DSP and mixing in the digital section between the DAIs but
because the DSP includes sample rate conversion the DAIs can be
configured separately and we don't have to worry about propagating DSP
through.

Essentially, I have front-end DAI link represents PCM stream while
back-end DAI link represents physical hardware path. Irrespective
of PCM configuration of front-end DAI link, I want CPU DAI and CODEC
DAI of backend DAI link configured to the same PCM configuration. DSP
can handle resampling/downmixing. How to achieve this use case in
soc-dsp implementation is not obvious to me. In existing soc-dsp
implementation, back-end does not get activated unless front-end is
routed to back-end. Then, PCM parameters of front-end gets propagated
to CPU driver and codec driver of back-end DAI link. I don't see how I
would be able to pass PCM configuration specifically for back-end.


One thing I should mention which I've been working on and which may
(depending on the design of your hardware) be a better match for you is
providing a mechanism for setting up DAI links and starting streams on
them in kernel space based on DAPM routing, with DAPM propagating over
these links automatically.  This is mostly intended for representing
things like basebands where you'll have a DAI link that's going to be
running in one of a small number of configurations (often only one)
connected to something else along the lines of:

    CODEC<   8kHz mono>   Baseband

so the idea is that to the user you can have a couple of pin switches
(or whatever else can be represented) in the baseband to say that the
baseband is passing audio and then DAPM will be extended to figure out
that it should start up the audio intefaces and configure their params
without needing userspace to do it just like it can if the link between
the two were analogue.


Yes, I do have use case in mind which requires functionality as you described to activate back-end DAI link without front-end DAI being
activated. DAPM seems to be most appropriate approach.

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux