ALSA -> pulseaudio channel mapping, what is it (and why?)

ALSA -> pulseaudio channel mapping, what is it (and why?)

[frederik]

Dear ALSA developers,

I ran into a problem which seems to be caused by some lines in
"alsa-plugins-1.1.8/pulse/pcm_pulse.c".

The problem is that if I create a 6-channel PulseAudio device, and
then I configure an ALSA device in ~/.asoundrc to output to the
PulseAudio device, the channels of the ALSA device are mixed together
in various ways and don't correspond 1-1 with the channels of the
PulseAudio device.

I find this to be counter-intuitive. If I wanted channels to be mixed
and remapped in various ways, I would use the PulseAudio module
module-remap-sink on the PulseAudio side, since AFAICT ALSA does not
support named channels. I would not expect remixing to happen in the
ALSA->Pulse bridge, since the relevant PCM plugin contains no channel
map parameter.

I don't even know what channel map I should give the PulseAudio device
in order to prevent remixing from occurring. The file pcm_pulse.c
contains the lines:

        for (c = pcm->ss.channels; c > 0; c--)
                if (pa_channel_map_init_auto(&map, c, PA_CHANNEL_MAP_ALSA))
                        break;

This refers to a macro in /usr/include/pulse/channelmap.h:

    /** \cond fulldocs */
        PA_CHANNEL_MAP_ALSA,
        /**< The default mapping used by ALSA. This mapping is probably
         * not too useful since ALSA's default channel mapping depends on
         * the device string used. */
    /** \endcond */

The comment says that the ALSA mapping is "not too useful" - so why
are we using it? Also, how do I find out what it is, if it "depends on
the device string used"?

My preference would simply be to have a 1-1 channel map in pcm_pulse,
so that a PulseAudio device with 6 channels will turn into an ALSA
device with THE SAME 6 CHANNELS. No mixing. Mixing is confusing in
this context, and seems undocumented outside of the code.

I tried using aux0 thru aux5 as the PulseAudio channel map, to prevent
geometry-based remixing. However, this results in silence - apparently
none of the 6 ALSA channels end up going anywhere. That was also
unexpected. Since I am playing 6-channel audio to a 6-channel device,
which emulates another 6-channel device, I would have thought that the
channel mapping wouldn't be complicated. Instead, it appears that the
PulseAudio sink needs to have channels with specific names in order to
receive data from ALSA.

Can we fix this, or improve the user experience?

Thanks,

Frederick

Re: [alsa-devel] ALSA -> pulseaudio channel mapping, what is it (and why?)

[Tanu Kaskinen]

On Fri, 2019-05-03 at 11:05 -0700, frederik@ofb.net wrote:
> Dear ALSA developers,
> 
> I ran into a problem which seems to be caused by some lines in
> "alsa-plugins-1.1.8/pulse/pcm_pulse.c".
> 
> The problem is that if I create a 6-channel PulseAudio device, and
> then I configure an ALSA device in ~/.asoundrc to output to the
> PulseAudio device, the channels of the ALSA device are mixed together
> in various ways and don't correspond 1-1 with the channels of the
> PulseAudio device.
> 
> I find this to be counter-intuitive. If I wanted channels to be mixed
> and remapped in various ways, I would use the PulseAudio module
> module-remap-sink on the PulseAudio side, since AFAICT ALSA does not
> support named channels.

There is an API for querying and configuring PCM device channel maps.
pcm_pulse.c doesn't seem to implement that API, though, so applications
are expected to use the default channel map, and if that doesn't match
the sink channel map, then PulseAudio will do the remapping (and
possibly remixing, if the channel maps differ in other ways than just
channel order).

> I would not expect remixing to happen in the
> ALSA->Pulse bridge, since the relevant PCM plugin contains no channel
> map parameter.

The remixing happens in PulseAudio, not in pcm_pulse.c. pcm_pulse.c
just tells PulseAudio the channel map that the stream uses.

> I don't even know what channel map I should give the PulseAudio device
> in order to prevent remixing from occurring. The file pcm_pulse.c
> contains the lines:
> 
>         for (c = pcm->ss.channels; c > 0; c--)
>                 if (pa_channel_map_init_auto(&map, c, PA_CHANNEL_MAP_ALSA))
>                         break;
> 
> This refers to a macro in /usr/include/pulse/channelmap.h:
> 
>     /** \cond fulldocs */
>         PA_CHANNEL_MAP_ALSA,
>         /**< The default mapping used by ALSA. This mapping is probably
>          * not too useful since ALSA's default channel mapping depends on
>          * the device string used. */
>     /** \endcond */
> 
> The comment says that the ALSA mapping is "not too useful" - so why
> are we using it?

pcm_pulse.c has to specify some channel map. Do you have better
proposals than PA_CHANNEL_MAP_ALSA?

> Also, how do I find out what it is, if it "depends on
> the device string used"?

There's currently no way to query the sink channel map through the ALSA
API. There's snd_pcm_get_chmap() that pcm_pulse.c could maybe
implement. There's the complication that usually the pulse PCM uses the
default sink, and the default sink can change at any time, so the
channel map can change at any time too, but that's probably not a huge
problem in practice.

> My preference would simply be to have a 1-1 channel map in pcm_pulse,
> so that a PulseAudio device with 6 channels will turn into an ALSA
> device with THE SAME 6 CHANNELS. No mixing. Mixing is confusing in
> this context, and seems undocumented outside of the code.

Remapping/remixing is very much expected in usual media playback cases.
If you have a 5.1 movie, it's easier for the player application to play
the audio in whatever channel order it wants and let the sound server
to remap and remix as necessary.

> I tried using aux0 thru aux5 as the PulseAudio channel map, to prevent
> geometry-based remixing. However, this results in silence - apparently
> none of the 6 ALSA channels end up going anywhere. That was also
> unexpected. Since I am playing 6-channel audio to a 6-channel device,
> which emulates another 6-channel device, I would have thought that the
> channel mapping wouldn't be complicated. Instead, it appears that the
> PulseAudio sink needs to have channels with specific names in order to
> receive data from ALSA.
> 
> Can we fix this, or improve the user experience?

What's the sink channel map in PulseAudio and what's your application's
channel map? Apparently one of them is not using the default ALSA map
for 6 channels.

If your application is not using the default channel map, why not?

If the sink is not using the default channel map, then it's expected
that PulseAudio shuffles the channels around, otherwise audio meant for
the front left speaker could end up in the rear right speaker, for
example. Do you have a use case for ignoring the channel map? Maybe the
SND_PCM_NO_AUTO_CHANNELS flag could be used in pcm_pulse.c to disable
channel remapping (I'm not volunteering to implement that, though).

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Re: [alsa-devel] ALSA -> pulseaudio channel mapping, what is it (and why?)

[frederik]

Dear Tanu,

Thanks for your reply. I made comments inline:

On Mon, May 06, 2019 at 02:04:37PM +0300, Tanu Kaskinen wrote:
>On Fri, 2019-05-03 at 11:05 -0700, frederik@ofb.net wrote:
>> Dear ALSA developers,
>>
>> I ran into a problem which seems to be caused by some lines in
>> "alsa-plugins-1.1.8/pulse/pcm_pulse.c".
>>
>> The problem is that if I create a 6-channel PulseAudio device, and
>> then I configure an ALSA device in ~/.asoundrc to output to the
>> PulseAudio device, the channels of the ALSA device are mixed together
>> in various ways and don't correspond 1-1 with the channels of the
>> PulseAudio device.
>>
>> I find this to be counter-intuitive. If I wanted channels to be mixed
>> and remapped in various ways, I would use the PulseAudio module
>> module-remap-sink on the PulseAudio side, since AFAICT ALSA does not
>> support named channels.
>
>There is an API for querying and configuring PCM device channel maps.
>pcm_pulse.c doesn't seem to implement that API, though, so applications
>are expected to use the default channel map, and if that doesn't match
>the sink channel map, then PulseAudio will do the remapping (and
>possibly remixing, if the channel maps differ in other ways than just
>channel order).
>
>> I would not expect remixing to happen in the
>> ALSA->Pulse bridge, since the relevant PCM plugin contains no channel
>> map parameter.
>
>The remixing happens in PulseAudio, not in pcm_pulse.c. pcm_pulse.c
>just tells PulseAudio the channel map that the stream uses.

Yes, I understand that much.

>> I don't even know what channel map I should give the PulseAudio device
>> in order to prevent remixing from occurring. The file pcm_pulse.c
>> contains the lines:
>>
>>         for (c = pcm->ss.channels; c > 0; c--)
>>                 if (pa_channel_map_init_auto(&map, c, PA_CHANNEL_MAP_ALSA))
>>                         break;
>>
>> This refers to a macro in /usr/include/pulse/channelmap.h:
>>
>>     /** \cond fulldocs */
>>         PA_CHANNEL_MAP_ALSA,
>>         /**< The default mapping used by ALSA. This mapping is probably
>>          * not too useful since ALSA's default channel mapping depends on
>>          * the device string used. */
>>     /** \endcond */
>>
>> The comment says that the ALSA mapping is "not too useful" - so why
>> are we using it?
>
>pcm_pulse.c has to specify some channel map. Do you have better
>proposals than PA_CHANNEL_MAP_ALSA?

What's wrong with using the channel map of the underlying PulseAudio
sink? Maybe that's another way of phrasing what I was trying to
communicate in my first email. I just want the channels to go straight
through.

Obviously this would have to be something that users would enable with
an option (in the ALSA config), to preserve backwards compatibility,
but I don't see what's undesirable about it.

>> Also, how do I find out what it is, if it "depends on
>> the device string used"?
>
>There's currently no way to query the sink channel map through the ALSA
>API. There's snd_pcm_get_chmap() that pcm_pulse.c could maybe
>implement. There's the complication that usually the pulse PCM uses the
>default sink, and the default sink can change at any time, so the
>channel map can change at any time too, but that's probably not a huge
>problem in practice.
>
>> My preference would simply be to have a 1-1 channel map in pcm_pulse,
>> so that a PulseAudio device with 6 channels will turn into an ALSA
>> device with THE SAME 6 CHANNELS. No mixing. Mixing is confusing in
>> this context, and seems undocumented outside of the code.
>
>Remapping/remixing is very much expected in usual media playback cases.
>If you have a 5.1 movie, it's easier for the player application to play
>the audio in whatever channel order it wants and let the sound server
>to remap and remix as necessary.

Does this currently happen correctly with pcm_pulse? For example if I
play a movie with 6-channel (e.g. 5.1) sound through an ALSA "pulse"
PCM, do the channels get delivered correctly to PulseAudio? How does
ALSA know which ones are which?

I'm asking because you said "it's easier", but that would only be the
case if it works. What happens when my media player tries to play a
4-channel file, with named channels, to the 6-channel ALSA device?
Does "the sound server [..] remap and remix as necessary" in this
case? I know PulseAudio does it, but I wasn't aware about ALSA.

>> I tried using aux0 thru aux5 as the PulseAudio channel map, to prevent
>> geometry-based remixing. However, this results in silence - apparently
>> none of the 6 ALSA channels end up going anywhere. That was also
>> unexpected. Since I am playing 6-channel audio to a 6-channel device,
>> which emulates another 6-channel device, I would have thought that the
>> channel mapping wouldn't be complicated. Instead, it appears that the
>> PulseAudio sink needs to have channels with specific names in order to
>> receive data from ALSA.
>>
>> Can we fix this, or improve the user experience?
>
>What's the sink channel map in PulseAudio and what's your application's
>channel map? Apparently one of them is not using the default ALSA map
>for 6 channels.
>
>If your application is not using the default channel map, why not?

Well, as I mentioned I don't know what the default map is, I don't
know where it's documented and I don't know how to look it up or query
it. I only know it exists because of /usr/include/pulse/channelmap.h.

OK I found "pa_channel_map_init_auto" in
pulseaudio/src/pulse/channelmap.c. Maybe the pcm_pulse documentation
(which is where on my hard drive?) should point to this file, or
RFC3551 which is mentioned in the comments? Hope this is making sense.

>If the sink is not using the default channel map, then it's expected
>that PulseAudio shuffles the channels around, otherwise audio meant for
>the front left speaker could end up in the rear right speaker, for
>example.

I'm playing 6-channel audio to a 6-channel sink. It's a
"module-combine-sink" with 3 stereo sinks from USB soundcards. I
specified the channel map simply because I need to say which channels
go to which of the devices. If I could call the channels a,b,c,d,e,f
then I would do that. If I knew what the default map was then maybe
that would be a better solution; however currently the whole thing is
configured by a script, so I would have to have to know the default
map for not just 6 channels but 8, 10, 12, etc., depending on how many
speakers the user decided to connect. Also, there is no "subwoofer" so
I'm not sure that I want PA_CHANNEL_POSITION_LFE to be one of the
channels, I remember seeing something about special processing that is
applied to LFE channels?

Obviously I sometimes want to upmix stereo to my 6 speakers, but
that's something that I'd rather configure separately, rather than
using default channel definitions. For example if I have two
microphones, then I could write a script that plays sound through each
channel and uses the mics to figure out good upmix coefficients from
left and right stereo.

> Do you have a use case for ignoring the channel map? Maybe the
> SND_PCM_NO_AUTO_CHANNELS flag could be used in pcm_pulse.c to
> disable channel remapping (I'm not volunteering to implement that,
> though).

What is SND_PCM_NO_AUTO_CHANNELS, I see it in
alsa-lib-1.1.1/src/pcm/pcm_plug.c but I don't understand what it is. I
don't understand how ALSA does automatic conversion between PCMs with
different channel counts. I would have thought that you need an
"upmix" or "multi" device. I didn't even realize that ALSA has named
channel maps, although I see that you mentioned earlier that there is
an API for this.

Thank you for your time.

Frederick
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss