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