[pulseaudio-discuss] Messing around with surround, also found a patch

[Tanu Kaskinen]

On Fri, 2012-10-05 at 22:45 -0300, Adriano Moura wrote:
> I've been using pulseaudio with surround content for quite a bit and
> found some oddities around.
> 
> When playing 5.1, 5.0 or 6.1 content, surround channels are labeled as
> REAR channels. This might be fine for people with up to 6.1 output
> since the surround channels are also labeled as REAR anyways, and most
> setups physically arrange it as a SIDE channel (not behind the
> listener, but exactly +/-90º) . However, once you try (for ex) 5.1
> over 7.1 the 5.1 REAR channel ends up as the 7.1 REAR channel which is
> supposed to be behind the listener in a 7.1 setup. Ideally 5.1 REAR
> would end up as 7.1 SIDE which matches the same physical arrangement.

I didn't get why 5.1 REAR should end up in 7.1 SIDE. If the content
creator decided to put audio in a REAR channel, why shouldn't it be
played to a REAR speaker? Is 5.1 content actually created with the
assumption that in practice the so-called "rear" channels end up in
"side" speakers?

> One way to achieve this is changing 5.0/5.1/6.1 ch map to use SIDE
> instead of REAR.
> 
> Another little nitpick is the lack of 6.1 mappings. Quite a bit of
> software rely on "pa_channel_map_init_auto" to find a usable mapping
> but fails because there is no case for 7 channel mapping, or it just
> returns a plainly wrong one. For example, running a 6.1 movie with
> smplayer/mplayer would fail because no 7ch mapping was available in
> "PA_CHANNEL_MAP_ALSA".

I think PA_CHANNEL_MAP_ALSA should be strictly bound to the channel
convention that alsa uses with its various surround devices. I think
there's no alsa surround device for 6.1, so it makes sense not to define
anything for 6.1 in pulseaudio either for PA_CHANNEL_MAP_ALSA.

It sounds like mplayer is likely buggy in this regard - I think it
should set the channel map based on the content, not just assume that
all 7-channel content uses the same channel map. The content should in
most cases include the full channel map information. If there really is
such crappy content types for multi-channel audio which don't include
the channel map information, then I think mplayer should use
PA_CHANNEL_MAP_DEFAULT instead of PA_CHANNEL_MAP_ALSA. Currently the
default definition is AIFF, though, which doesn't contain any mappings
above 6 channels, and even the 6-channel definition doesn't seem to be
very suitable for being the default (no LFE channel). So, I think this
is a bug in pulseaudio. PA_CHANNEL_MAP_DEFAULT needs to be redefined
somehow. After that's done, mplayer can use PA_CHANNEL_MAP_DEFAULT
instead of PA_CHANNEL_MAP_ALSA (but only in those cases where the
content doesn't contain any channel map information).

> Also, "PA_CHANNEL_MAP_WAVEEX" gives many wrong channel maps. As far as
> I know WAVEEX is supposed to work with a bitmask to select which
> channels you want to work with, not to religiously give the channels
> in the order the MS documentation provides. Let me put it better, you
> are supposed to hide the channels you don't need but still keep what
> you need at the same original order. Since "pa_channel_map_init_auto"
> does not provide any means to pass this bitmask, the WAVEEX condition
> should just return what is most common for X channels.
> For example, 7.1 (8ch) should have
> FL, FR, FC, LFE, RL, RR, SL, RR in this order, and not
> FL, FR, FC, LFE, RL, RR, FLC, FRC.
> Anything between RR and SL would be ignored.
> This, for example, fixes every single openal game/app with 7.1 sound.
> You can actually play minecraft and amnesia without a silly "Front
> Left of Center" channel making it's presence known.

I don't understand why openal would use PA_CHANNEL_MAP_WAVEEX to define
its channel map, though. When openal creates a stream in pulseaudio, I
would expect it to know exactly the channel map, and if it doesn't match
with the WAVEEX definition, then it should use some other definition (or
initialize the pa_channel_map struct manually).

That said, if the mapping that you suggest for WAVEEX isn't any less
conformant than the current mapping, this sounds like a useful change to
make. Potentially it can break other applications that assume that the
mapping is what it is now, but I find the existence of such applications
quite unlikely...

> The good thing is.. I've come up with a patch that fixes these issues.
> But I cant guarantee it's a 100% fix. Fixing WAVEEX can't be done
> without guessing what some random app means about "4 channels!" and
> swapping REAR for SIDE in 5.0/5.1/6.1 mappings is probably not be the
> best way to solve this issue.

If it really is the case that the content authors use the 5.1 rear
channels as if they were side channels, then I think the best place to
adapt to that would be calc_map_table() in src/pulsecore/resampler.c.

Thanks for your efforts!

-- 
Tanu