[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