[alsa-devel] [PATCH] ASoC: Add optional pointer to machine audio routes to snd_soc_card

Mark Brown broonie at opensource.wolfsonmicro.com
Tue Dec 21 17:29:40 CET 2010

On Tue, Dec 21, 2010 at 09:42:15AM +0200, Peter Ujfalusi wrote:
> On Monday 20 December 2010 14:02:01 ext Mark Brown wrote:

> > I don't see anything different here with multi-component?  The general
> > idea is that by default a floating output or input should be treated as
> > connected.

> As I said, it is another issue. It is just that for me it is more logical to 
> treat the floating inputs/outputws as not connected. It is not that big problem, 
> since from machine driver I can mark the unsused pins as nc.

The reason it's this way round is that this way we default to allowing
audio to pass through the system.  Generally when people are bringing up
a new system they're much more worried about the hardware being at all
functional than power optimisation - in many systems power isn't a
concern at all.  This way there's less obstacles to getting audio up,
and people can go through and optimise later if they need to.

> > > Now if you enable the bypass on codec2, it shall not bring up the codec2
> > > bias, since we do not have full route.

> > This isn't abundantly clear - there may potentially be analogue
> > interface issues if two devices which aren't connected aren't both
> > powered up and down together.  Robust system design should avoid these
> > issues but I'd prefer it if software were conservative and at the very
> > least always had an option to ensure everything is powered on at once.

> If you look at things in card level, I still think that in the case I have 
> described the codec2 shall not change bias level.
> If it does before the playback starts on the codec1, we might end up hearing the 
> pop from codec1 powering up, since the codec2 path has been already up (with the 
> speaker enabled).

Like I say if the speaker is unconditionally enabled DAPM will keep the
speaker output path up anyway so it's going to be up regardless of
anything else.  If the bias management functions are enabling output
drivers they're doing something wrong anyway.

More information about the Alsa-devel mailing list