|
»
« Return to Thread: new panning algorithm
Re: new panning algorithm
by Chris Robinson-5
::
Rate this Message:
On Sunday 18 January 2009 7:29:22 am Christian Borss wrote:
> As a nice task for a rainy sunday I took the time to port my panning
> algorithm to OpenAL Soft 1.6. You can find my patch against the current
> GIT version of openal-soft on the web server of our institute:
>
> http://www2.ika.rub.de/borss/openal_panning_borss_git20090118.diff
Thanks for updating it. :)
> My panning algorithm is intended for multi-speaker setups like a 5.1 or
> 7.1 surround setup. The current implementation uses only 4 of these
> speakers, i.e. the front and the rear speakers, for spatial rendering.
> The center and the back surround speakers are not used.
The center channel isn't used in spatial calculations because it's a bit
ambiguous as to where it should be. The absolute center? Or between the front
speakers? Often times in movies, the center speaker is left out for sound
effects and used specifically as a voice track and/or some "special" sounds to
draw the viewer's attention to.
For 7.1 surround-sound setups, it should use 6 speakers (2 front, 2 side, 2
rear).
> What the current
> implementation does is linear panning between the left and the right
> speakers and in addition linear panning between the front and the rear
> speakers. This may be a proper panning method for a quadrophony setup
> where you have 4 speakers at +/-45° and +/-135° but for a up to date
> surround system with 5 and more speakers this is a clear limitation.
> Besides the limitation of the reduced number of involved speakers, the
> current implementation results in displaced auditory events. A speaker
> setup which conforms with the ITU-R BS.775 recommendation, has its front
> speakers at +/-30° and its rear speaker at +/-110°. This is the typical
> 5.1 surround setup. Now, if one uses the currunt panning implementation
> in combination with a typical 5.1 speaker setup, the space between the
> front speakers is compressed and the space between the rear speakers is
> expanded. Why does this matter? Imagine a sound source which circles
> around the listener with constant speed. Due to the compression/
> expansion, the auditory event (the perceived sound source) moves no
> longer with constant velocity - it's slower in the frontal region and
> faster in the back region.
This, however, was a concern. I had planned on fixing this by making the
scalars used configurable, though it would've added some complexity to the
calculations.
> My panning algorithm takes the speaker arrangement into account to cope
> with this issue. In my implementation, the directional part of panning
> values are pre-calculated and stored in a look-up-table (LUT). For
> speed optimization, the resolution of this LUT is not constant. Instead
> of using atanf() to determine the source direction from which the LUT
> index is derived, I derive the index from the ratio |x| / ( |x| + |z| )
> which is faster to compute than atanf(). I tested my algorithm with
> ioquake3 in combination with the openarena data files and it worked
> pretty well. The localization of the sound sources is clearly improved.
> As I'm not a gamer I can't provide information about how well it works
> with other games. Please give it a try and let me know if it works for
> you!
A quick test showed it seem to work well. I have question, though.. with this:
pos = round(QUADRANT_NUM * aluFabs(im) / (aluFabs(re) + aluFabs(im)));
what is supposed to happen if re and im are 0? Since they're the -Z and X
coords, this is quite possible for head-relative sources that are left at
0,0,0, and given the code, it would cause a 0/0 which wouldn't be very good.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel
> As a nice task for a rainy sunday I took the time to port my panning
> algorithm to OpenAL Soft 1.6. You can find my patch against the current
> GIT version of openal-soft on the web server of our institute:
>
> http://www2.ika.rub.de/borss/openal_panning_borss_git20090118.diff
Thanks for updating it. :)
> My panning algorithm is intended for multi-speaker setups like a 5.1 or
> 7.1 surround setup. The current implementation uses only 4 of these
> speakers, i.e. the front and the rear speakers, for spatial rendering.
> The center and the back surround speakers are not used.
The center channel isn't used in spatial calculations because it's a bit
ambiguous as to where it should be. The absolute center? Or between the front
speakers? Often times in movies, the center speaker is left out for sound
effects and used specifically as a voice track and/or some "special" sounds to
draw the viewer's attention to.
For 7.1 surround-sound setups, it should use 6 speakers (2 front, 2 side, 2
rear).
> What the current
> implementation does is linear panning between the left and the right
> speakers and in addition linear panning between the front and the rear
> speakers. This may be a proper panning method for a quadrophony setup
> where you have 4 speakers at +/-45° and +/-135° but for a up to date
> surround system with 5 and more speakers this is a clear limitation.
> Besides the limitation of the reduced number of involved speakers, the
> current implementation results in displaced auditory events. A speaker
> setup which conforms with the ITU-R BS.775 recommendation, has its front
> speakers at +/-30° and its rear speaker at +/-110°. This is the typical
> 5.1 surround setup. Now, if one uses the currunt panning implementation
> in combination with a typical 5.1 speaker setup, the space between the
> front speakers is compressed and the space between the rear speakers is
> expanded. Why does this matter? Imagine a sound source which circles
> around the listener with constant speed. Due to the compression/
> expansion, the auditory event (the perceived sound source) moves no
> longer with constant velocity - it's slower in the frontal region and
> faster in the back region.
This, however, was a concern. I had planned on fixing this by making the
scalars used configurable, though it would've added some complexity to the
calculations.
> My panning algorithm takes the speaker arrangement into account to cope
> with this issue. In my implementation, the directional part of panning
> values are pre-calculated and stored in a look-up-table (LUT). For
> speed optimization, the resolution of this LUT is not constant. Instead
> of using atanf() to determine the source direction from which the LUT
> index is derived, I derive the index from the ratio |x| / ( |x| + |z| )
> which is faster to compute than atanf(). I tested my algorithm with
> ioquake3 in combination with the openarena data files and it worked
> pretty well. The localization of the sound sources is clearly improved.
> As I'm not a gamer I can't provide information about how well it works
> with other games. Please give it a try and let me know if it works for
> you!
A quick test showed it seem to work well. I have question, though.. with this:
pos = round(QUADRANT_NUM * aluFabs(im) / (aluFabs(re) + aluFabs(im)));
what is supposed to happen if re and im are 0? Since they're the -Z and X
coords, this is quite possible for head-relative sources that are left at
0,0,0, and given the code, it would cause a 0/0 which wouldn't be very good.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel
« Return to Thread: new panning algorithm
| Free embeddable forum powered by Nabble | Forum Help |
