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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.