How to define card specific pcm devices?

How to define card specific pcm devices?

[Tanu Kaskinen]

Hi,

I'm writing UCM configuration for RX-51 (Nokia N900), and I have a
problem: "hw:RX51" can't be opened in mono mode, but there's only one
integrated mono microphone, and its audio is routed to the left input
channel. Applications will get only silence in the right channel when
they use "hw:RX51".

The best solution that I have come up is to define a pcm that converts
"hw:RX51" into a mono device. The problem is that I don't know how
exactly to do that. I guess the route plugin can be used for that:

pcm.rx51_mono_from_left {
        type route
        slave.pcm hw:RX51
        slave.channels 2
        ttable.0.0 1
}

I tried putting that definition in /usr/share/alsa/cards/RX-51.conf (and
also RX51.conf, since it's not entirely clear to me when the dash should
be omitted). I have this in the UCM configuration:

Value {
        CapturePCM "rx51_mono_from_left"
        CaptureChannels "1"
}

This is printed to the PulseAudio log:

(alsa-lib)pcm.c: Unknown PCM rx51_mono_from_left

So the rx51_mono_from_left definition is not loaded. I'm not terribly
surprised: I guess the card configuration files are loaded only when
necessary, and when PulseAudio tries to open "rx51_mono_from_left",
alsa-lib can't really know that it's somehow related to the RX-51 card.

How should I solve this?

-- 
Tanu

Re: How to define card specific pcm devices?

[Tanu Kaskinen]

Ping?

If card specific pcm definitions are not possible, would it be
acceptable to have a generic "front_left:CARD" or "first_channel:CARD"
pcm, which would transform "front:CARD" or "hw:CARD" into a mono device?

-- Tanu


On Fri, 2012-08-10 at 14:25 +0300, Tanu Kaskinen wrote:
> Hi,
> 
> I'm writing UCM configuration for RX-51 (Nokia N900), and I have a
> problem: "hw:RX51" can't be opened in mono mode, but there's only one
> integrated mono microphone, and its audio is routed to the left input
> channel. Applications will get only silence in the right channel when
> they use "hw:RX51".
> 
> The best solution that I have come up is to define a pcm that converts
> "hw:RX51" into a mono device. The problem is that I don't know how
> exactly to do that. I guess the route plugin can be used for that:
> 
> pcm.rx51_mono_from_left {
>         type route
>         slave.pcm hw:RX51
>         slave.channels 2
>         ttable.0.0 1
> }
> 
> I tried putting that definition in /usr/share/alsa/cards/RX-51.conf (and
> also RX51.conf, since it's not entirely clear to me when the dash should
> be omitted). I have this in the UCM configuration:
> 
> Value {
>         CapturePCM "rx51_mono_from_left"
>         CaptureChannels "1"
> }
> 
> This is printed to the PulseAudio log:
> 
> (alsa-lib)pcm.c: Unknown PCM rx51_mono_from_left
> 
> So the rx51_mono_from_left definition is not loaded. I'm not terribly
> surprised: I guess the card configuration files are loaded only when
> necessary, and when PulseAudio tries to open "rx51_mono_from_left",
> alsa-lib can't really know that it's somehow related to the RX-51 card.
> 
> How should I solve this?
> 

Re: How to define card specific pcm devices?

[Raymond Yau]

2012-8-17 下午10:51 於 "Tanu Kaskinen" <tanu.kaskinen@digia.com> 寫道：
>
> Ping?
>
> If card specific pcm definitions are not possible, would it be
> acceptable to have a generic "front_left:CARD" or "first_channel:CARD"
> pcm, which would transform "front:CARD" or "hw:CARD" into a mono device?

As pulseaudio server use SND_PCM_NO_AUTO_CHANNEL which diable channel
conversion, this left channel device only work with other alsa applications
except pulseaudio when your sound card does not support mono.

http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=ff4af902cf4ac07c5f1da3b6dacbb3195c7c222d

the solution is to change the mixing in pulseaudio by using left channel
for this mic and those stereo mic with inverted phase , and average for
mono playback device . stereo mic and line-in

how about the 4 channel mic?

>
> -- Tanu
>
>
> On Fri, 2012-08-10 at 14:25 +0300, Tanu Kaskinen wrote:
> > Hi,
> >
> > I'm writing UCM configuration for RX-51 (Nokia N900), and I have a
> > problem: "hw:RX51" can't be opened in mono mode, but there's only one
> > integrated mono microphone, and its audio is routed to the left input
> > channel. Applications will get only silence in the right channel when
> > they use "hw:RX51".
> >
> > The best solution that I have come up is to define a pcm that converts
> > "hw:RX51" into a mono device. The problem is that I don't know how
> > exactly to do that. I guess the route plugin can be used for that:
> >
> > pcm.rx51_mono_from_left {
> >         type route
> >         slave.pcm hw:RX51
> >         slave.channels 2
> >         ttable.0.0 1
> > }
> >
> > I tried putting that definition in /usr/share/alsa/cards/RX-51.conf (and
> > also RX51.conf, since it's not entirely clear to me when the dash should
> > be omitted). I have this in the UCM configuration:
> >
> > Value {
> >         CapturePCM "rx51_mono_from_left"
> >         CaptureChannels "1"
> > }
> >
> > This is printed to the PulseAudio log:
> >
> > (alsa-lib)pcm.c: Unknown PCM rx51_mono_from_left
> >
> > So the rx51_mono_from_left definition is not loaded. I'm not terribly
> > surprised: I guess the card configuration files are loaded only when
> > necessary, and when PulseAudio tries to open "rx51_mono_from_left",
> > alsa-lib can't really know that it's somehow related to the RX-51 card.
> >
> > How should I solve this?
> >
>
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: How to define card specific pcm devices?

[Tanu Kaskinen]

On Sat, 2012-08-18 at 09:26 +0800, Raymond Yau wrote:
> 2012-8-17 下午10:51 於 "Tanu Kaskinen" <tanu.kaskinen@digia.com> 寫道：
> >
> > Ping?
> >
> > If card specific pcm definitions are not possible, would it be
> > acceptable to have a generic "front_left:CARD" or "first_channel:CARD"
> > pcm, which would transform "front:CARD" or "hw:CARD" into a mono device?
> 
> As pulseaudio server use SND_PCM_NO_AUTO_CHANNEL which diable channel
> conversion, this left channel device only work with other alsa applications
> except pulseaudio when your sound card does not support mono.

So are you suggesting that Alsa doesn't need any changes, because all
other applications allow automatic channel conversion, and therefore
this is a PulseAudio specific problem and should be fixed in PulseAudio?

> 
> http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=ff4af902cf4ac07c5f1da3b6dacbb3195c7c222d
> 
> the solution is to change the mixing in pulseaudio by using left channel
> for this mic and those stereo mic with inverted phase , and average for
> mono playback device . stereo mic and line-in

Sure this can be fixed in PulseAudio with card specific configuration,
but if at all possible, I want to avoid card specific configuration in
PulseAudio. I believe one of the main points of UCM is to avoid hardware
specific configuration in applications using Alsa.

This could be solved also by stating in the UCM configuration that only
the left channel of the stereo device contains useful data. This would
avoid having card specific configuration in applications, but handling
that information adds more complexity in applications. Having a proper
mono device in Alsa would avoid any changes in applications.

> how about the 4 channel mic?

What about it? The discussion stopped when I asked what should be the
name for the device. I asked whether "4channelinput" would be good, but
got no answers. At PulseAudio side we figured that "hw" works well
enough in practice, so there was not much pressure for me to keep the
discussion alive.

-- 
Tanu

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: How to define card specific pcm devices?

[Raymond Yau]

>
> > how about the 4 channel mic?
>
> What about it? The discussion stopped when I asked what should be the
> name for the device. I asked whether "4channelinput" would be good, but
> got no answers. At PulseAudio side we figured that "hw" works well
> enough in practice

http://www.rrfx.net/2009/11/ps3-eye-4-channel-audio-tests-on-ubuntu.html

the geometry of the microphone array is an important factor for how to
perform downmixing to mono as there are delay between the four mics and the
channel map of mic array is different from the channel map of surround
speakers

Re: How to define card specific pcm devices?

[Raymond Yau]

2012-8-18 下午12:09 於 "Tanu Kaskinen" <tanuk@iki.fi> 寫道：
>
> On Sat, 2012-08-18 at 09:26 +0800, Raymond Yau wrote:
> > 2012-8-17 下午10:51 於 "Tanu Kaskinen" <tanu.kaskinen@digia.com> 寫道：
> > >
> > > Ping?
> > >
> > > If card specific pcm definitions are not possible, would it be
> > > acceptable to have a generic "front_left:CARD" or "first_channel:CARD"
> > > pcm, which would transform "front:CARD" or "hw:CARD" into a mono
device?
> >
> > As pulseaudio server use SND_PCM_NO_AUTO_CHANNEL which diable channel
> > conversion, this left channel device only work with other alsa
applications
> > except pulseaudio when your sound card does not support mono.
>
> So are you suggesting that Alsa doesn't need any changes, because all
> other applications allow automatic channel conversion, and therefore
> this is a PulseAudio specific problem and should be fixed in PulseAudio?

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

the  channel map for those stereo mic which have out of phase left and
right channel is  either [left,-left] or [-right,right]

some stereo mic may has [null,right]
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: How to define card specific pcm devices?

[Tanu Kaskinen]

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"

		# Channel names match the constants in
                # Takashi's proposed channel map API
                CaptureChannelMap "FL, NA"
        }

}

Opinions? (Liam added to CC - am I right in that you should be CC'd in
all UCM related discussions?)

-- 
Tanu

Re: How to define card specific pcm devices?

[Liam Girdwood]

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.

>                         # 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.

>         
>         Opinions? (Liam added to CC - am I right in that you should be
>         CC'd in
>         all UCM related discussions?)

Yes, please and Mark too (now on CC).

Thanks

Liam

> 

Re: How to define card specific pcm devices?

[Tanu Kaskinen]

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.

-- 
Tanu

Re: 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@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

Re: How to define card specific pcm devices?

[Tanu Kaskinen]

On Fri, 2012-09-07 at 11:35 +0200, Takashi Iwai wrote:
> At Fri, 07 Sep 2012 12:03:34 +0300,
> Tanu Kaskinen wrote:
> > 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.

I now realized that even if we had snd_pcm_query_chmaps_from_name(), the
channel map information would still be needed in the UCM configuration.
For example on N900, all audio playback and capture is done through hw:0
with two channels (the pcm can't be opened in mono mode). In different
situations the channel map is different: sometimes only one channel of
the pcm is useful. Getting a list of channel maps from
snd_pcm_query_chmaps_from_hw() doesn't tell PulseAudio which channel map
is the right one, so this information needs to come from the UCM
configuration.

So, I was wrong when I said that the main reason for having the channel
map information in UCM is that the chmap API can only be used when the
pcm is open.

-- 
Tanu