« Return to Thread: new panning algorithm

Re: new panning algorithm

by Chris Robinson-5 :: Rate this Message:

On Monday 19 January 2009 1:39:24 am Christian Borss wrote:

> The center speaker is typically placed between the front speakers as
> recommended by "ITU-R BS.775":
>
>
> http://en.wikipedia.org/wiki/Surround_sound#5.1_Channel_Surround_.283-2_Ste
>reo.29_.28digital_discrete:_Dolby_Digital.2C_DTS.2C_SDDS.29
> http://www.sengpielaudio.com/Surround-ITU-Wiedergabe.pdf
>
> The second web site contains documents for German "Tonmeister" (sound
> engineers).

I see.

> >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.
>
> I think, a rocket fired by an opponent in the front in a computer game
> should definitely draw the gamers attention to the front. :-)

True enough. Though there's not much saying the rocket fire in front of the
player is any more important than the one to his side..

> >For 7.1 surround-sound setups, it should use 6 speakers (2 front, 2 side,
> > 2 rear).
>
> The center speaker was introduced to improve the localization in the
> frontal region. So, why not make use of it?

Code complexity mostly. It's easier to pan around in a symmetrical "grid"
using physically-correct math (ie. centering using a gain of sqrt(0.5)) than
an imbalanced grid with 3 sections in front and 2 in back. It was something I
was eventually going to look into, but it wasn't a high priority.

> I saw in the source code that you use this arrangement for 6.1 surround
> setups. Thats why I used the front/side/rear-back speaker setup also in
> my code. But normaly I would expect a
>
> 1 center
> 2 front
> 2 side
> 1 rear-back
>
> speaker arrangement:
>
>
> http://en.wikipedia.org/wiki/Surround_sound#6.1_Channel_Surround_.28digital
>_discrete:_DTS-ES.29
>
> Would you agree to change the configuration to a DTS-ES arrangement?

Looking over that wikipedia page, it does seem that's the intended
arrangement, yes. I suppose that affects the AL_FORMAT_61CHN* formats as well.
I really need to clean up the mixer loop to properly remix multichannel
buffers..

> >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.
>
> In this case, DirGain is set to zero
>
> DirGain = aluSqrt(Position[0] * Position[0] + Position[2] * Position[2]);

Ah, right. Yeah, it shouldn't be too difficult to handle that, then. Just a
simple if > 0 check.

Though as "luck" would have it, I started implementing a Phonon backend just
before this patch was brought up, and I've been fighting with it trying to get
it not to crash. Unfortunately this means I can't (really shouldn't) go about
applying/tweaking this while I have other changes being worked on, and I don't
want to split my attention between the two and accidentally overlook
something. If I can't get the Phonon backend working I'll just set it aside
for another day, but whether I get it in or drop it, I'll dig deeper into this
patch right after.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

« Return to Thread: new panning algorithm