[openal] stereo separation issue with a stereo source

[Chris Robinson]

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 
early/mid-October.

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 
everything else.

> 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 
ambisonics).

> 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).