[openal] Speaker test

[Anders Genell]

> 5 juni 2017 kl. 03:03 skrev Chris Robinson <chris.kcat at gmail.com>:
> 
>> On 06/04/2017 01:14 PM, Anders Genell wrote:
>> So, does OpenAL Soft use a matrix of predefined possible speaker
>> positions when decoding b-format (there are som standard ones related
>> to the wave-x format in some way, isn't there?) or how is the
>> b-format otherwise decoded to a speaker array?
> 
> Basically it takes an accumulation of how much each B-Format channel contributes to the direction the speaker is in. That's a pretty gross oversimplification, but it's the simplest way to explain it that I can think of.
> 
> The general concept is, given a sound panned in B-Format to some direction, all the speakers contribute to make a physical plane wave coming from that direction. The more speakers you have, and the higher the ambisonic order, the more accurate the plane wave can be.
> 
>> You say a multi-channel audio file may or may not have corresponding
>> output channels, but if the number or channels in the file or stream
>> exactly matches the number of channels in the output format set in
>> alsoft.conf should they then at least match channel to channel?
> 
> I tried doing that once, but I found there was a perceptual volume difference when an input channel is matched directly to an output channel, compared to being panned. At least for surround sound output. And for stereo, there's the recently-implemented stereo_angles extension that allows rotating the stereo channels, so even if the channel names match, their intended positions might not.
> 
> And things like HRTF, which is stereo output but uses filters to provide consistent reproduction of multi-channel sources (you wouldn't want to directly match input to output with HRTF anyway, unless the sound is already made for headphones).
> 
> One of the ideas I currently have in mind is something where you can query the number of output channels, get text labels for each channel, and some method to "link" a source to play on a specific output channel instead of going through the panning stuff. This should be reasonably flexible since it wouldn't restrict OpenAL to using a list of predefined formats, or a list of predefined channels. Not too keen on the idea of text labels to identify channels, but I don't think predefined enums would be the best idea for ease of extendability.

That would be absolutely perfect for a speaker-test kind of thing! 

> 
>> Also, what kind of b-format decoder does OpenAL Soft use? Would it be
>> possible to have it decode to a horribly skewed speaker setup that
>> would need both angular and time/phase correction?
> 
> Not sure about angular correction, but time/phase correction on speakers is possible. Simply provide an .ambdec config file that specifies the proper speaker distances, and OpenAL Soft will apply the necessary delays and gains to make them sound equidistant.

Oh?! Fantastic!
Is it documented somewhere how to implement this? Looking at e.g. Fons Adriaensen's ambisonics decoder for linux, it seems angles should be possible too.
http://kokkinizita.linuxaudio.org/linuxaudio/adec-pict.html

Regards,
Anders
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openal.org/pipermail/openal/attachments/20170605/a0a541fc/attachment.html>