On Tue, Aug 21, 2012 at 04:49:56PM +0200, Takashi Iwai wrote:
Mark Brown wrote:
Or perhaps what we want to do here is define the channel mapping in terms of saying "I'm connecting to this input/output" and then use the jack interface to describe all inputs and outputs rather than just jacks (making sure it's easy to see which ones can change state)?
It's an interesting idea. But, in the case of HDMI, there are no multiple jacks, so this won't fit.
Surely the jack should be able to change state, though?
What I had in my mind originally is to provide the definition of values in TLV, and get/set points the value index.
However, this doesn't help much for multiple output cases like ice1712. So far, I ignored that case intentionally. The primary goal of this API is to provide a way for apps to decide the channel map for multi-channel streams. If multiple positions are given, what they should do? It'd be just confusing.
This sort of stuff is why I was suggesting providing a mechanism for saying "fall back to tracing the routing graph" - obviously there's an implementation to do there but it should provide ultimate support for whatever mappings people can dreamm up.
At least, some fixed multiple outputs could be covered by the free definition of the chmap value like above (e.g. by allowing multiple assignments per channel in the definition block). But whether to cover all flexible multiple outputs per channel, I hesitate to go forward...
I agree, I think it'd be too complex to cover every case purely in channel mapping.