[openal] stereo separation issue with a stereo source

Chris Robinson chris.kcat at gmail.com
Sun Feb 8 17:13:02 EST 2015

On 02/08/2015 07:53 AM, Lubomir I. Ivanov wrote:
> i was testing some MOD tracker decoding with playback from openal-soft
> and i immediately noticed the narrower stereo field on the front
> speakers of the quad setup (because the panning adjustment does
> exactly that effectively) compared to the same PCM playing in another
> peace of software, so i've decided to ask if there is an option to
> toggle it off.

I see. Ultimately, yeah, OpenAL Soft uses a different (IMO smarter) 
remixing algorithm that places individual input channels to where they 
should be regardless of the output speaker configuration, rather than a 
rudimentary label matching and doubling scheme that can alter the 
intended sound field and volume.

In a sense, you can think of it like how OpenGL discourages working with 
screen pixels directly, instead using a virtual space and fitting what 
you draw into that space regardless of how many pixels are actually 
available. In that same vein, OpenAL discourages working with speakers 
directly, instead using a virtual space and fitting what you play into 
that space regardless of how many speakers are actually available.

> that would be great, but please note that i don't really insist or
> want to create you *tons* of extra work.
> if it's *way too* difficult to implement, leave it be or lower it's
> priority perhaps until more people complain.

It's certainly not difficult. But there's a number of things to weigh in 
deciding the best course of action. For instance...

Although the volume imbalance can be accounted for, it won't be perfect, 
meaning the left or right channel of a stereo buffer may not get the 
same volume as a mono buffer panned to that same location. It'll be 
close, but not quite the same.

It'll provide a more accurate reproduction to match the stereo input 
channels to the front-left/right output speakers, presuming those 
speakers are placed (roughly) correctly.

Though if they're not placed correctly, OpenAL could still theoretically 
correct for the difference with panning, presuming it knows (i.e. the 
user specifying updated coefficients for their unique layout).

It does make sense to match input channels to output when such a 
matching is valid, applying as few transforms as possible.

But, working internally with a speaker-agnostic flow allows for 
potentially better rendering. Effects could render to a full 3D sound 
field, like having reverb apply reflections along separate vertical, 
horizontal, and depth axises (which can also rotate according to 
listener orientation). Having an ambisonics decoder done as a final step 
means it can efficiently enhance otherwise limited reproduction too -- 
for example, rather than simply mapping stereo output to the X axis, it 
can optionally apply filters to imitate depth for sounds that should be 
behind the listener (which would include the aforementioned depth 
reflections from reverb), or to extending the horizontal axis outside of 
the physical speaker area.

Though how much would that really matter in the end? There's no telling 
when such things would be done, either.

But also, the fewer special-cases, the better.

More information about the openal mailing list