At Tue, 21 Aug 2012 17:27:06 +0100, Mark Brown wrote:
On Tue, Aug 21, 2012 at 05:38:34PM +0200, Clemens Ladisch wrote:
Takashi Iwai wrote:
It's an interesting idea. But, in the case of HDMI, there are no multiple jacks, so this won't fit. [...] The primary goal of this API is to provide a way for apps to decide the channel map for multi-channel streams.
Indeed; including the jack location/type would go beyond what the channel map is useful for. Playback applications know what kind of multichannel stream they're playing, but they definitely do _not_ want to decice if the output should go to the front or back panel.
The channel mapping is a _stream_ configuration, the other routing choices are device setup.
Perhaps I'm missing something but why would the availability of additional information be a problem for applications here?
Because apps don't know what to do for such a case. The APIs in other sound subsystems (see PA or gstreamer) don't allow such setups.
The idea was purely to punt the description of the outputs attached to the stream to somewhere we already need to use to describe the outputs rather than having to map the two formats together.
Yeah, passing more info is fine. But if it isn't compatible, it doesn't have to be the same controller elements as channel map. Or, we may put a flag in the query TLV to indicate it's not standard, etc...
At the moment, we lack an API to provide topology information. But whatever form it takes, it should probably be independent of the channel mapping. (I'll see if I can find time to do something about my media framework patches until next week.)
For media controller? Everyone who's looked at in detail has expressed concern about it being too heavyweight...
It's my concern, too, but hey, let's see. Clemens might give some magic :)
Takashi