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