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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20120821/0b7dba32/attachment.sig>