At Fri, 07 Sep 2012 12:03:34 +0300, Tanu Kaskinen wrote:
On Thu, 2012-09-06 at 18:18 +0100, Liam Girdwood wrote:
On Wed, 2012-09-05 at 12:24 +0100, Girdwood, Liam wrote:
On 5 September 2012 06:41, Tanu Kaskinen tanuk@iki.fi wrote: On Wed, 2012-08-29 at 09:44 +0800, Raymond Yau wrote: > strictly speaking your mic is not a true stereo mic and the channel > map is [left, null] instead of the normal map [left,right] of line-in > or stereo mic
I think specifying the channel map like you suggest would be a good solution. Supporting it would require some extra work in PulseAudio, but I think PulseAudio will anyway have to be extended to query the channel map information from UCM. Now the problem is that UCM doesn't provide the channel map information at all. Should the channel map be provided in the device "Value" section? Like this: SectionDevice."my-mono-mic" { ... Value { # Does this value become redundant if # the "CaptureChannelMap" value is added? CaptureChannels "2"I would expect to see a "1" here unless we cannot open the pcm in mono mode.
Me too, but the original problem was precisely that the pcm only supports stereo, and the second channel is silent.
# Channel names match the constants in # Takashi's proposed channel map API CaptureChannelMap "FL, NA" } }This seems fine and should be a simple patch for UCM too. Pulsaudio could use the map information/preference from UCM (like above) to configure the driver using Takashi's new channel map API.
Ok, I plan to work on this soonish.
A question about the syntax: should the PHASE_INVERSE and DRIVER_SPEC flags be supported also here, or is it enough to have just a simple list of channels?
I think the syntax will have to support the flags, because if DRIVER_SPEC is set, then the channel position is effectively unknown to PulseAudio. The channel map may potentially affect routing decisions, which is the main reason why the channel map information is needed in UCM in addition to the new channel map API. The channel map API can be used only with an already opened pcm handle, which is not very useful when doing routing decisions.
Well, the kernel side API doesn't require that the PCM to be open. It's just a read of TLV from a control element.
The problem is that the configuration is evaluated only at open in alsa-lib PCM abstraction. That's the only reason chmap query takes snd_pcm_t handle.
In other words, it's pretty easy to provide a query function limited only for hw device, such as
snd_pcm_chmap_query_t **snd_pcm_query_chmaps_from_hw(int card, int device, int substream);
Ideally it should be a query from a PCM name string like
snd_pcm_chmap_query_t **snd_pcm_query_chmaps_from_name(const char *name);
But it's hard for now without opening a PCM because we need to parse down the definition of the given PCM and the underlying plugin expansions require the opens of their slave PCMs.
Takashi