From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
To: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org, patches@opensource.wolfsonmicro.com,
lgirdwood@gmail.com
Subject: Re: [RFC PATCH] ASoC: wm_adsp: Change ADSPs to be mixer widgets rather the PGAs
Date: Wed, 18 Dec 2013 17:05:21 +0000 [thread overview]
Message-ID: <20131218170521.GG11138@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20131218161902.GW28455@sirena.org.uk>
On Wed, Dec 18, 2013 at 04:19:02PM +0000, Mark Brown wrote:
> On Wed, Dec 18, 2013 at 02:14:23PM +0000, Charles Keepax wrote:
> > On Wed, Dec 18, 2013 at 01:23:43PM +0000, Mark Brown wrote:
>
> > > Not the physical output, the DSP output into the rest of the device. It
> > > would be very surprising if it powered up making noise.
>
> > Regrettably, I don't believe there is a way to mute the output of
> > the DSP. Muting the physical output does fix the issue. I could
>
> So the DSP powers up outputing stuff? That seems like an interesting
> design decision (it might need something to reset the buffers on power
> down I guess).
It is not sure it is so much a design decision but there is an
audible pop when the DSP core enable bit is set if it is
connected to an unmuted output.
>
> > look at seperating out the physical power up of the core and
> > starting the firmware to be seperate widgets, that might also
> > fix the issue and would mean the firmware wouldn't run until the
> > input signal was clean, but I am not sure if feels that neat a
> > solution.
>
> That sort of split is something I'd considered doing in the past anyway
> - it would be beneficial to be able to overlap the DSP startup with
> other activities so the delays while bringing up the outputs could be
> happening while the DSPs are downloading firmware or the firmware is
> starting up for example. You could also overlap stuff with the RAM
> startup if that's now taking longer.
Ok this looks like a potentially viable solution, and I hadn't
considered the potential benefits it could have to speed up the
audio path bring up time, I shall have a bash at implementing it
and see where I get to.
Thanks,
Charles
prev parent reply other threads:[~2013-12-18 17:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-18 10:53 [RFC PATCH] ASoC: wm_adsp: Change ADSPs to be mixer widgets rather the PGAs Charles Keepax
2013-12-18 11:27 ` Mark Brown
2013-12-18 13:14 ` Charles Keepax
2013-12-18 13:23 ` Mark Brown
2013-12-18 14:14 ` Charles Keepax
2013-12-18 16:19 ` Mark Brown
2013-12-18 17:05 ` Charles Keepax [this message]
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=20131218170521.GG11138@opensource.wolfsonmicro.com \
--to=ckeepax@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=patches@opensource.wolfsonmicro.com \
/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.