[openal] stereo separation issue with a stereo source

[Lubomir I. Ivanov]

On 8 February 2015 at 16:16, Chris Robinson <chris.kcat at gmail.com> wrote:
> 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 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.

given a source that contains a stereo music buffer, one might expect a
hard panned tambourine to remain hardpanned without channel bleed
regardless of the configuration (mostly).

looking at AL_SOFT_direct_channels's description it seems to do what
it does and i would agree that if a stereo buffer contains it's own
spacial effects applying virtualization on that can certainly be
considered as quality reduction by some.

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

not sure how that correlates to AL_SOFT_direct_channels, but 1) is
probably the option i was thinking of to be available as the "toggle"
alternative (optimally per source, i assume).
but it's up to you and other developers to decide what is optimal.

having the option to not always take speaker position and angle into
account is not necessarily a bad thing, because first of all not all
people even know how to place their speakers properly - me being one
of them.

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

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.

i could be one of those less than 1% that will ever ask why it happens...

lubomir
--