[openal] stereo separation issue with a stereo source
chris.kcat at gmail.com
Sun Feb 8 09:16:30 EST 2015
On 02/07/2015 11:25 AM, Lubomir I. Ivanov wrote:
> i see, so the "direct channels" extension is the only way it seems?
Well, what exactly are you trying to do? The stereo field is reproduced
just fine the way it is now, stretching nominally from about -30 to +30
degrees, even if it's not exactly done intuitively. Outside of some
pretty specific use-cases (sounds that have had HRTF/binaural filters
pre-applied, or when each output speaker drives an independent signal;
basically treating them as separate mono speakers), the
AL_SOFT_direct_channels extension should not be used.
> i'd be surprised if no one has ever brought this during the OpenAL history.
> for quadro specifically or pehaps for other even-numbered channel
> setups the virtualization should be a toggle, i would think.
The ambisonics-based panning algorithm is a relatively recent change to
OpenAL Soft (done after the last release), although I think this is the
first time it's been brought up since I made the change in
What OpenAL Soft would need to do to avoid panning individual buffer
channels is either, 1) use a dumber remixing method that doesn't take
speaker positioning into account (which is what most software seems to
do), or 2) check if the buffer format can channel-match for a given
output format and fallback to panning otherwise. Choice 2 would be the
more sensible option to me, but aside from the volume imbalance (which
is likely fixable), there's still the issue of how to match channels.
If you match based on position, then it won't work for you anyway
because stereo input is positioned for +/-30 degrees, while quad output
has the front speakers at +/-45 degrees. However, if you match based on
channel label, you'll get errant results... with 5.1-rear output for
example, where the surround channels are connected to the rear-channel
outputs, 5.1 buffers won't match because they're expecting side
channels, but quad buffers will match even though the speakers aren't
placed properly for it.
The other option would be to simply special-case stereo buffers when
front-left and front-right outputs are available, and use panning for
> also the odd part is that no other modern software that i've seen
> virtualizes my quadro setup.
AFAIK, the Rapture3D driver by Blue Ripple Sound functions similarly.
Input channels for non-mono buffers are panned separately based on
virtual speaker layouts, and mixed into a 16-channel B-Format buffer.
That buffer is then rendered using higher-order ambisonics for output to
a given speaker setup. OpenAL Soft just mushes these two steps together
to avoid the intermediary B-Format buffer (though sometimes I think
about separating them too, if I could make reverb work better with
> it does detect the quadro layout - anything else of importance? the
> config file is simply missing as i don't have one.
That looks as I'd expect it to. OpenAL Soft's detecting the quad
configuration, so it's using quad panning coefficients.
> so your comment about "speaker matching" suggests that the
> viritualzation will be always on for anything above 2 channels and i
> would assume and there is no way to disable it with OpenAL?
Virtualization is always on regardless of the number of channels. The
issue you face is basically how it behaves when a virtual speaker
matches up with a physical speaker.
Currently, there is no way to work around the bleed over when playing
normal stereo buffers with surround sound output, but I am looking at
ways to avoid it (from within the lib, so apps don't have to do anything).
More information about the openal