Center Channel Problems with OpenAL-Soft above 1.16

[Kamastein]

I've been testing OpenAL-Soft out for a while now and it seems any versions abouve 1.16 including the newest ones don't tend to utilize the center channel properly the way it used to. Instead they seem to split the center channel signal to the front left and right. 1.17 and greater seem to do this.

I've been testing this out two ways on an iMac with an HDMI cable and 8 channel LPCM setup to a 5.1 surround sound system. Via the .dll in Wine with a supported game (like Mirror's Edge) or via .framework with a supported Mac game or .dylib with supported Mac game (like Killing Floor).

Also it would be handy to me if the binaries in the zip files included those latter files since I can't easily do it myself.

[kcat]

The way OpenAL Soft does panning was changed with 1.17. Previously with 1.16, it would just do simple pair-wise mixing between the two closest speakers to the intended sound position. However that doesn't work right for surround sound panning, causing the perceived position to be wrong.

With 1.17, OpenAL Soft started using an Ambisonic-based panning technique, which utilizes more speakers to help better localize sound positions. This is why a front-panned sound will also play on the front-left and front-right speakers along with front-center. With 1.18, this was extended to include frequency-dependent processing (taking into account how the brain localizes low-frequency sounds vs high-frequency) and near-field effects, meaning not only enhanced surround sound panning, but also an enhanced perception of depth (when properly configured).

Also it would be handy to me if the binaries in the zip files included those latter files since I can't easily do it myself.

Unfortunately I lack the means to build Mac dylibs or frameworks. I don't have access to a Mac, and cross-compiling to Mac doesn't seem to be a thing like cross-compiling to Windows is.

[Kamastein]

The problem with this newer way is that it seems to be sending the front panning sound to the front stereo pair LOUDER than to the center channel when the emitter is directly in front. If anything it should be louder in the center than the front left and right pair when something is directly in front of you. Otherwise it defeats the purpose of the center channel speaker.

I'm guessing this new behavior is supposed to simulate it getting louder\bigger when it gets up close as I imagine hypthetically speaking it'd make the sound go more "wide" when it gets close or when you get closer to it. But I think it might be aggressively panning to the front left and right too much\soon. Either that or it's a mode\way more intended for music or intended more for headphones or any system that does not have a center channel speaker.

With some dsound games I was wrapping them to OpenAL-Soft because that was the only way to get surround sound via them in Wine. But later on I noticed the built in dsound support for Wine was IMHO better in that regard. This seems to introduce different perhaps unintended (by the devs of the game) behavior to those games.

[kcat]

If anything it should be louder in the center than the front left and right pair when something is directly in front of you. Otherwise it defeats the purpose of the center channel speaker.

The front-center channel is actually more for dialog tracks than spatial audio. It's to help separate the focal character's speech from other sounds and ambiance so that it's clearer, and spreads out the energy (moving speech onto a separate channel reduces the maximum amplitude on each front channel, so as to require less gain compression even when sounds and speech are both in front). OpenAL even has the ALC_EXT_DEDICATED extension for that, to control the mix of dialog between being on the front-center channel vs spatially panned.

Aside from that, 5.1 is just a very imbalanced layout, with 3 speakers in the front 60 degree area and only 2 for the back 140 degree area (and each side having 80 degrees between 2 speakers). It's completely non-uniform, making an automated method to properly reproduce spatial audio difficult. So there needs to be tradeoffs, and one such tradeoff includes reducing the influence of the front-center speaker, preferring front-left and front-right to handle spatial sounds. Some other methods I've heard about actually cut the front-center speaker entirely from the panning output.

The old method wasn't any better for spatial audio. While pair-wise mixing could utilize each speaker directly given the sound location to make it sound "sharply" positioned, accurate positioning of sounds was pretty bad if the desired position wasn't near a speaker. And since the point is to reproduce sounds from all around the listener, not just at the speaker positions, a different panning method is utilized that can better do that.

[Kamastein]

I think therein lies the rub though. Much of what I want to go to the center is dialog esp. during i game cut scenes... and one can't depend on a game using ALC_EXT_DEDICATED esp. if it's been ported (in which case I'd also like the original behavior). I'd also prefer anything that's directly in front to be coming from the center particularly for off axis listening. But that's just me. To me those other methods sound terrible to be frank.

Also, something to realize is that layouts above 5.1 typically use it as a base\bed (including the new immersive audio formats like ATMOS and DTS:X that have overhead speakers). Also, actually.. the "rear" speakers in 5.1 shouldn't be to the rear instead they should be to the sides.

http://www.wendycarlos.com/surround/1)srnd.jpg

Which I personally go with. It's a classic blunder to put them to the rear in 5.1 rather than to the sides. The above layout gives me better panning between the front and surround channels giving me phantom in between I've noticed.

"But we're interested in an optimum plan or two for Human Surround Sound. Since the back of our heads is not nearly as sensitive to sound directionality and nuance (not to mention a poorer frequency response, and unfortunate interference as sounds move away from the rear of one ear towards the rear of the other), we ought not "waste" too much effort trying to obtain what we can't: a uniform sound field. That's where so many surround concepts fall down, assuming we humans can hear in 360 degrees and follow it all accurately."

[kcat]

Also, actually.. the "rear" speakers in 5.1 shouldn't be to the rear instead they should be to the sides.

According to Dolby's guide, the surround speakers can be between 90 degrees at the least and 110 degrees at the most. As OpenAL Soft has the front speakers at the maximum 30 degrees (for a 60-degree left/right separation, which is what most stereo content is designed for), it only makes sense to me to have the surround speakers at the maximum 110 degrees also. Having them slightly behind also improves the perception of rear-originating sound, since at 90 degrees the front/back axis becomes completely ambiguous. Kind of a misnomer to call it "surround" sound if it just covers the front half and doesn't even attempt to surround the listener, I think.

What I'd be interested in is knowing how 5.1 mixes are generally made. As far as I know, it's not terribly uncommon to have an ambisonic mix to start with, and generate various stereo, 5/7.1 surround sound, and even binaural mixes from that. While I do feel that what OpenAL Soft does now for surround sound is a step above pair-wise mixing, there's still more that can be done with both ambisonics and just more generally. Of course, OpenAL has to compromise on the fact that it's producing real-time game audio, where various qualities of the mix are much more flexible (when generating a 5.1 mix from premade audio tracks, you can tune the generator knowing what the audio is that you're working with, what's important, what's not, and how to best use the speakers to create the desired phantom images; with OpenAL an app can be doing anything, and the user will expect reasonable reproduction of what it was over configurable speaker setups, and expect it done with as little latency as possible). Interestingly, newer systems like Dolby Atmos take this more flexible real-time mixing scheme, rather than completely pre-made discrete channel mixes.

[Kamastein]

Actually, I kinda agree with you about having them a little behind the listeners as right now I actually have my surround speakers a few feet above ear level (the Dolby guidelines recommend ear level but I kinda differ with them on that), angled inward a bit sort of firing down at the listening position (inspired by the cinema) and to the sides but a little behind me sort of in line with the backrest of my sofa which I feel gives me the best results as far as also having "behind you" sound in 5.1. I've actually spent quite some time setting up and calibrating my system.

You might notice though like at the cinema (probably because of necessity) the surrounds are on the side walls and tend to be at your side and the most well.. audible speakers are the ones closest to your row... and in order to have fully "behind you" sound they added those rear channels to 7.1 (and above) surround.

Yes, I've noticed cinema is trending towards real-time audio mixing with ATMOS and the like. I'm looking forward to upgrading to that someday.

Also, "Kind of a misnomer to call it "surround" sound if it just covers the front half and doesn't even attempt to surround the listener, I think."

This is precisely why I decided to hook up an HDMI cable up to my receiver and get multichannel going rather than just throwing my hands up and saying screw it and just run the plain old stereo mix with no encoding whatsoever via surround matrixing (aka Prologic, only one game I know of has specific encoding for this.. Darkplaces, but I digress). :P With that method I can pretty much guarantee that all mono\front sounds would go to the center. But I'd rather have "real" surround sound.

As an aside I had an audio production professor in college who was against surround sound and panning in general saying it should only be used sparingly because it's "distracting" to him. :P

[kcat]

In regards to better utilizing the front-center speaker, I recently ran across this. A module to take stereo input and process it to create a clean 3-channel output. It's actually fairly similar to what I suspected; convert it to mid-side and use that to pan across three output channels in some way. The only thing I'm not sure about are the two "sine/cosine potential divider"s, in particular how they'd be set (I presume the potential dividers are essentially pan-pots to control how much of each band is sent back to the M channel for matrixing to FL/FR, vs how much is sent to the FC channel).

Taking that, one option to consider is: decode the main ambisonic mix to 4-channel (5.1 excluding the front-center), then apply the upmix to the front stereo channels to get a 5-channel mix (the stable 3-channel result of that process, and the 2 surround channels from the ambisonic decode). I can't say how well it will work in practice, but it's something to look into.

[Kamastein]

Sounds promising. Particularly if it also affects cut scenes that where encoded in two channel as well.

[kcat]

The latest Git commit adds an option to this effect. The default 5.1 decoder configuration now excludes the front-center channel from positional sounds (the preexisting itu5.1.ambdec preset is still there which includes front-center, but it should not be used with this new option; and I think it may be worth dropping it as I feel the new method provides a better overall response). In addition to the updated decoder, you'll want to enable the new config option (in %AppData%\alsoft.ini on Windows, or $HOME/.config/alsoft.conf elsewhere):

[general]
front-stablizer = true

That uses frequency-dependent processing to generate a front-center channel output, altering the front-left and front-right with it, to create a more "stable" front sound image. There's still room to tweak it given that I couldn't find any references to what some of the parameters should be, but using my best guesses, it sounds fairly good in my opinion.

[mirh]

Some other methods I've heard about actually cut the front-center speaker entirely from the panning output.

This is in fact what I have seen in mass effect, starting with version 1.18. front-stablizer=true fixes this, but I'm not sure why the default behaviour should have a speaker completely dead. Muffled and whatever filtered is fine, but not even a grenade or dialogue in front of me seemed to produce an output here.

[kcat]

front-stablizer=true fixes this, but I'm not sure why the default behaviour should have a speaker completely dead.

The speaker is used for sources set to direct_channels and play a 5.1 (or higher) buffer, or use the dedicated_dialog effect. But either way, there were a number a reasons that option wasn't on by default (some are no longer relevant):

• It's extra processing for surround sound output, which I tried to avoid since I didn't want surround sound to be that much more costly than plain stereo (aside from the cost of mixing the extra channels themselves, of course). I remember with the certain engines, enabling 5.1 surround sound would tank performance while stereo was perfectly fine, and I wanted to avoid something like that happening. I don't think this is really a big deal now, though, since I've not seen or heard of this cause any performance issues.
• It negatively affected direct_channels sources since it filtered those all the same, instead of letting them through directly as intended (even a direct_channel 5/6/7.1 buffer source would upmix the left/right channels to the center, despite it already providing a center channel). This has been fixed in 1.21.
• The center channel upmix would still get applied even if a user selected a decoder that included the front-center channel. They would have to also toggle front-stablizer separately when changing the decoder. This has also been fixed in 1.21.
• I wasn't sure whether the stablizer/upmix produced better or acceptable results in the general case, maintaining improved stereo separation while making good use of the front-center channel and not messing up the sound field reconstruction. The growing consensus seems to be that it's preferable to have on, though.

So I probably will turn it on by default for the next release. At least for 5.1 and 6.1... I think the 6-channel regular speaker layout created with 7.1 output may be more ideal for the ambisonic decode than trying find something for the front-center speaker to play, leaving the front-center for direct channel or dedicated dialog effects only.

[mirh]

Wow, this is very nice. I'm a bit afraid the great majority of games has no such "dedicated channel" handling though (or if not any, this is what seemed the case already with #72)

[dborel]

I had similar problems with the new surround51 panner, but in my case it wasn't sending any sound to the rear channels. "front-stablizer = true" changed the behavior slightly, but there still wasn't anything coming out of my rear right speaker. I noticed that surround51rear still produces a reasonably good pan, but is more computationally expensive than it was in older versions of ALSoft. Switching to quad gave me the best balance of performance and directionality.