Hi,
sorry for the late reply, but I have constant mail reception problems, and I do not receive mails, or randomly receiving them...
On Monday 20 December 2010 14:02:01 ext Mark Brown wrote:
What I was thinking is more like to move the DAPM map from codec domain up to card level. What I mean is, that when you build up your ASoC card, the DAPM map/routes are going to be attached to the card, and not to the codec.
At runtime everyting is treated (or should be treated) as one map - the
That's good.
One thing that might need to be changed in DAPM is how we handle the connected/not connected endpoints. Currently if you have DAPM_OUTPUT, and you do not connect it to speaker/HP/line, it is handled like it has some connection. In multi comp this might be not what we want. Also the treatment of the inputs might need to be changed.
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.
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). If the DAPM treats this situation in a same way, if it was within one codec, than we are able to reduce the pop noise on the output. It is not a black magic to do so, and since we have single DAPM map/routing it can be done with small effort. I think.
If we do not have the: {"codec2 Line in", NULL, "codec1 to line out"}, in the machine driver, we shall not power the bypass path in codec2, even if the switch is on, since the machine does not specified any connection.
IMHO this is more logical, than treating non connected OUTPUTs/INPUTs as connected. But this is a different issue.
I don't see any relationship between multi-component and the state of the pins here? If there's a path through the device the path would be there even if there's only one device in the system.
Yeah, it is different issue. If the card has been treated as one device, I see no problems. But if we treat a codec as device within a card, we might have some issues, but it can be solved with small effort.