From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Patrick Lai <plai@codeaurora.org>
Cc: alsa-devel@alsa-project.org, waiw@codeaurora.org,
pl bossart <bossart.nospam@gmail.com>,
asishb@codeaurora.org, jaywang@codeaurora.org,
Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: soc-dsp questions
Date: Fri, 10 Jun 2011 10:42:30 +0100 [thread overview]
Message-ID: <20110610094226.GA26436@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4DF1C08F.90306@codeaurora.org>
On Thu, Jun 09, 2011 at 11:58:23PM -0700, Patrick Lai wrote:
> On 4/26/2011 3:18 AM, Mark Brown wrote:
> >This is roughly the same thing I've been talking about for digital DAPM
> >links. I've got code which runs at the minute but the implementation
> >sucks too much, should be able to pull out some of the preparation work
> >in the next day or so.
> Is it possible I can take an early glimpse of implementation? I do have
No, the code ended up colliding with something someone else had done and
wasn't worth saving so I just threw it away. However I did get the
external interface upstream before I did that - that was the code to
support not providing a platform driver for a DAI. What the code did
was to look to see if there was a platform driver and if there wasn't
it'd add some DAPM nodes and links which would bring up the DAI with no
userspace involvement.
> use cases that PCM is exchanged between two back-ends. Right now, I
> need to define DUMMY hostless front-end DAI links to bring up the
> back-ends. Another query is how hardware parameters is passed to
> back-end with your design? Not able to choose back-end channel mode
For the initial code they were just inferred from the capabilities of
the DAI - all the cases I'm interested in are for interoperation with
something that's fixed format at one end of the link so I could punt on
that issue. I'd thought about allowing the dai_link to have a set of
hw_params settings stored in it which the user would be given an
enumeration to select from but hadn't actually done anything concrete
with it.
> independent of front-end channel mode is a big problem especially if
> channel mode is more than stereo. DSP is handles upmixing/downmixing
> happens in our design. Right now, we force channel mode to stereo. So,
> for the scenario which we just want mono input, we have codec
> configured to pick up single mic input to both left and right channel.
> DSP takes average of two channels into mono stream. Once we need to
> support > 2 channel recording, it's wasteful to go with the same
> approach if all we want is mono input. Did we talk about this topic
That might be handlable by either of the methods I was suggesting above.
Of course depending on the algorithms you're running the DSP may want
more mics than it's producing output channels - beam forming or noise
cancellation are the obvious examples there.
> during workshop? Why is my problem also a concern on OMAP4/ABE?
Do you mean not also a concern? I *believe* OMAP is passing the
configuration through to the external DAI using the front end/back end
connection so the format gets selected by the app when it does a record,
possibly with rewriting through the hook functions in the machine driver.
next prev parent reply other threads:[~2011-06-10 9:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-25 22:01 soc-dsp questions pl bossart
2011-04-26 9:41 ` Liam Girdwood
2011-04-26 10:18 ` Mark Brown
2011-06-10 6:58 ` Patrick Lai
2011-06-10 9:42 ` Mark Brown [this message]
2011-06-11 1:19 ` Patrick Lai
2011-06-11 11:48 ` Mark Brown
2011-06-13 4:55 ` Patrick Lai
2011-06-13 18:01 ` Liam Girdwood
2011-06-13 17:55 ` Liam Girdwood
2011-06-13 17:49 ` Liam Girdwood
-- strict thread matches above, loose matches on Subject: below --
2011-11-08 8:22 Vinod Koul
2011-11-08 20:20 ` Girdwood, Liam
2011-11-09 8:04 ` Vinod Koul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110610094226.GA26436@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=asishb@codeaurora.org \
--cc=bossart.nospam@gmail.com \
--cc=jaywang@codeaurora.org \
--cc=lrg@slimlogic.co.uk \
--cc=plai@codeaurora.org \
--cc=waiw@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox