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
