[alsa-devel] How to define card specific pcm devices?

[Takashi Iwai]

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 at 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