AL_SOFT_direct_channels

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

AL_SOFT_direct_channels

Chris Robinson-5
This and the loopback extension are what I'm hoping to have done before
releasing OpenAL Soft 1.14.

OpenAL Soft somewhat recently got support for HRTF filters for when using
headphones, however some stereo audio tracks may already be designed to play
with headphones which makes it not sound as good when fed through HRTF
filters. Something like this was requested as a way to let such audio pass
through to the output without going through spatialization.


Name

    AL_SOFT_direct_channels

Contributors

    Chris Robinson

Contact

    Chris Robinson (chris.kcat 'at' gmail.com)

Status

    In-progress

Dependancies

    This extension is written against the OpenAL 1.1 specification.

Overview

    This extension allows a multi-channel source to play without virtualized
    output speakers. By default, OpenAL requires buffer channels to be down-
    mixed to the output channel configuration, possibly using HRTF techniques
    to give a sense of speakers that may not be physically present. Sometimes
    audio tracks are authored with their own spatialization effects, where the
    AL's spatialization methods can cause a notable decrease in audio quality.

    This extension provides a mechanism for applications to specify whether
    audio should be filtered according to the AL's channel spatialization
    methods for multi-channel buffers.

Issues

    Q: Should this be a buffer property or source property?
    A: Source property. This gives more flexibility to the app to decide
       whether some piece of audio should be filtered or not.

    Q: Should this work on mono (3D) sources?
    A: No. Besides most people not having a mono speaker, or possibly even a
       front-center speaker, its main intent is for stereo tracks that have
       spatialization effects pre-applied.

    Q: Are environmental effects, provided by EFX for example, still applied?
    A: Yes. There's no compelling reason to disable them, particularly when
       the application has to enable them on a per-source basis in the first
       place.

New Procedures and Functions

    None.

New Tokens

    Accepted by the <paramName> parameter of alSourcei, alSourceiv,
    alGetSourcei, and alGetSourceiv:

        AL_DIRECT_CHANNELS_SOFT                  0x1033

Additions to Specification

    Append to Section 4.3.2, Source Attributes

    Table 4.x Channel Virtualization

    Name                       Signature  Values               Default
    -------------------------  ---------  -------------------  ----------
    AL_DIRECT_CHANNELS_SOFT    i, iv      AL_TRUE, AL_FALSE    AL_FALSE

    Description:
    AL_DIRECT_CHANNELS_SOFT set to AL_TRUE indicates the audio channels do not
    go through virtualization or spatialization and plays directly on the
    matching output channel if it exists, otherwise it is dropped. Applies
    only when playing non-mono buffers.

_______________________________________________
Openal-devel mailing list
[hidden email]
http://opensource.creative.com/mailman/listinfo/openal-devel
Reply | Threaded
Open this post in threaded view
|

Re: AL_SOFT_direct_channels

Jason Daly

Chris,

I guess I thought that it had been specified (i.e.: in the spec) that
multichannel sources wouldn't ever be spatialized, but I can't seem to
find that now.  Traditionally, at least the Loki and Creative
implementations followed this concept.  Only mono sources were
spatialized and stereo/multichannel sources were passed through.

Is this basically intended to formalize that idea?

--"J"


On 03/02/2012 10:12 AM, Chris Robinson wrote:

> This and the loopback extension are what I'm hoping to have done before
> releasing OpenAL Soft 1.14.
>
> OpenAL Soft somewhat recently got support for HRTF filters for when using
> headphones, however some stereo audio tracks may already be designed to play
> with headphones which makes it not sound as good when fed through HRTF
> filters. Something like this was requested as a way to let such audio pass
> through to the output without going through spatialization.
>
>
> Name
>
>      AL_SOFT_direct_channels
>
> Contributors
>
>      Chris Robinson
>
> Contact
>
>      Chris Robinson (chris.kcat 'at' gmail.com)
>
> Status
>
>      In-progress
>
> Dependancies
>
>      This extension is written against the OpenAL 1.1 specification.
>
> Overview
>
>      This extension allows a multi-channel source to play without virtualized
>      output speakers. By default, OpenAL requires buffer channels to be down-
>      mixed to the output channel configuration, possibly using HRTF techniques
>      to give a sense of speakers that may not be physically present. Sometimes
>      audio tracks are authored with their own spatialization effects, where the
>      AL's spatialization methods can cause a notable decrease in audio quality.
>
>      This extension provides a mechanism for applications to specify whether
>      audio should be filtered according to the AL's channel spatialization
>      methods for multi-channel buffers.
>
> Issues
>
>      Q: Should this be a buffer property or source property?
>      A: Source property. This gives more flexibility to the app to decide
>         whether some piece of audio should be filtered or not.
>
>      Q: Should this work on mono (3D) sources?
>      A: No. Besides most people not having a mono speaker, or possibly even a
>         front-center speaker, its main intent is for stereo tracks that have
>         spatialization effects pre-applied.
>
>      Q: Are environmental effects, provided by EFX for example, still applied?
>      A: Yes. There's no compelling reason to disable them, particularly when
>         the application has to enable them on a per-source basis in the first
>         place.
>
> New Procedures and Functions
>
>      None.
>
> New Tokens
>
>      Accepted by the<paramName>  parameter of alSourcei, alSourceiv,
>      alGetSourcei, and alGetSourceiv:
>
>          AL_DIRECT_CHANNELS_SOFT                  0x1033
>
> Additions to Specification
>
>      Append to Section 4.3.2, Source Attributes
>
>      Table 4.x Channel Virtualization
>
>      Name                       Signature  Values               Default
>      -------------------------  ---------  -------------------  ----------
>      AL_DIRECT_CHANNELS_SOFT    i, iv      AL_TRUE, AL_FALSE    AL_FALSE
>
>      Description:
>      AL_DIRECT_CHANNELS_SOFT set to AL_TRUE indicates the audio channels do not
>      go through virtualization or spatialization and plays directly on the
>      matching output channel if it exists, otherwise it is dropped. Applies
>      only when playing non-mono buffers.
>
> _______________________________________________
> Openal-devel mailing list
> [hidden email]
> http://opensource.creative.com/mailman/listinfo/openal-devel
>

_______________________________________________
Openal-devel mailing list
[hidden email]
http://opensource.creative.com/mailman/listinfo/openal-devel
Reply | Threaded
Open this post in threaded view
|

Re: AL_SOFT_direct_channels

Eric Wing
>From Section: 5.3.4. Specifying Buffer Content

Buffers containing audio data with more than one channel will be
played without 3D spatialization features – these formats are normally
used for background music.



On 3/2/12, Jason Daly <[hidden email]> wrote:

>
> Chris,
>
> I guess I thought that it had been specified (i.e.: in the spec) that
> multichannel sources wouldn't ever be spatialized, but I can't seem to
> find that now.  Traditionally, at least the Loki and Creative
> implementations followed this concept.  Only mono sources were
> spatialized and stereo/multichannel sources were passed through.
>
> Is this basically intended to formalize that idea?
>
> --"J"
>
>
> On 03/02/2012 10:12 AM, Chris Robinson wrote:
>> This and the loopback extension are what I'm hoping to have done before
>> releasing OpenAL Soft 1.14.
>>
>> OpenAL Soft somewhat recently got support for HRTF filters for when using
>> headphones, however some stereo audio tracks may already be designed to
>> play
>> with headphones which makes it not sound as good when fed through HRTF
>> filters. Something like this was requested as a way to let such audio pass
>> through to the output without going through spatialization.
>>
>>
>> Name
>>
>>      AL_SOFT_direct_channels
>>
>> Contributors
>>
>>      Chris Robinson
>>
>> Contact
>>
>>      Chris Robinson (chris.kcat 'at' gmail.com)
>>
>> Status
>>
>>      In-progress
>>
>> Dependancies
>>
>>      This extension is written against the OpenAL 1.1 specification.
>>
>> Overview
>>
>>      This extension allows a multi-channel source to play without
>> virtualized
>>      output speakers. By default, OpenAL requires buffer channels to be
>> down-
>>      mixed to the output channel configuration, possibly using HRTF
>> techniques
>>      to give a sense of speakers that may not be physically present.
>> Sometimes
>>      audio tracks are authored with their own spatialization effects,
>> where the
>>      AL's spatialization methods can cause a notable decrease in audio
>> quality.
>>
>>      This extension provides a mechanism for applications to specify
>> whether
>>      audio should be filtered according to the AL's channel spatialization
>>      methods for multi-channel buffers.
>>
>> Issues
>>
>>      Q: Should this be a buffer property or source property?
>>      A: Source property. This gives more flexibility to the app to decide
>>         whether some piece of audio should be filtered or not.
>>
>>      Q: Should this work on mono (3D) sources?
>>      A: No. Besides most people not having a mono speaker, or possibly
>> even a
>>         front-center speaker, its main intent is for stereo tracks that
>> have
>>         spatialization effects pre-applied.
>>
>>      Q: Are environmental effects, provided by EFX for example, still
>> applied?
>>      A: Yes. There's no compelling reason to disable them, particularly
>> when
>>         the application has to enable them on a per-source basis in the
>> first
>>         place.
>>
>> New Procedures and Functions
>>
>>      None.
>>
>> New Tokens
>>
>>      Accepted by the<paramName>  parameter of alSourcei, alSourceiv,
>>      alGetSourcei, and alGetSourceiv:
>>
>>          AL_DIRECT_CHANNELS_SOFT                  0x1033
>>
>> Additions to Specification
>>
>>      Append to Section 4.3.2, Source Attributes
>>
>>      Table 4.x Channel Virtualization
>>
>>      Name                       Signature  Values               Default
>>      -------------------------  ---------  -------------------  ----------
>>      AL_DIRECT_CHANNELS_SOFT    i, iv      AL_TRUE, AL_FALSE    AL_FALSE
>>
>>      Description:
>>      AL_DIRECT_CHANNELS_SOFT set to AL_TRUE indicates the audio channels
>> do not
>>      go through virtualization or spatialization and plays directly on the
>>      matching output channel if it exists, otherwise it is dropped.
>> Applies
>>      only when playing non-mono buffers.
>>
>> _______________________________________________
>> Openal-devel mailing list
>> [hidden email]
>> http://opensource.creative.com/mailman/listinfo/openal-devel
>>
>
> _______________________________________________
> Openal-devel mailing list
> [hidden email]
> http://opensource.creative.com/mailman/listinfo/openal-devel
>


--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

_______________________________________________
Openal-devel mailing list
[hidden email]
http://opensource.creative.com/mailman/listinfo/openal-devel
Reply | Threaded
Open this post in threaded view
|

Re: AL_SOFT_direct_channels

Chris Robinson-5
In reply to this post by Jason Daly
On Friday, March 02, 2012 2:29:45 PM Jason Daly wrote:
> I guess I thought that it had been specified (i.e.: in the spec) that
> multichannel sources wouldn't ever be spatialized, but I can't seem to
> find that now.

I figured wording this might be tricky.

Multi-channel sources aren't spatialized in the traditional sense (ie, using
AL_POSITION). However, the method OpenAL Soft has adopted for rendering them
is to give each channel an angle where it'll be placed in relation to the
listener. For instance, stereo sources will have the front-left channel at -30
degrees and the front-right channel at +30 degrees. You can see the other
setups here:
http://repo.or.cz/w/openal-soft.git/blob/44e10c4f6916060:/Alc/ALu.c#l66

Each channel is then positioned around the "listener" so that when rendered,
particularly with HRTF, it gives a spatial effect simulating the placement of
speakers. This ensures each input channel is properly panned and rendered,
regardless of the output channel configuration. Even without HRTF, if you have
wide-angle stereo speakers, for example, stereo sources will be panned to
simulate speakers at -30 and +30 degrees.

This works well enough for most audio, however for tracks that already have
their own spatialization effects, this method can interfere and reduce
playback quality. This extension is aimed to combat that, so channels don't go
through this virtualization step and just play directly on the output channels
as intended.
_______________________________________________
Openal-devel mailing list
[hidden email]
http://opensource.creative.com/mailman/listinfo/openal-devel
Reply | Threaded
Open this post in threaded view
|

Re: AL_SOFT_direct_channels

Jason Daly
On 3/2/2012 10:51 PM, Chris Robinson wrote:
> This works well enough for most audio, however for tracks that already
> have their own spatialization effects, this method can interfere and
> reduce playback quality. This extension is aimed to combat that, so
> channels don't go through this virtualization step and just play
> directly on the output channels as intended.

OK, I get it now.  Subtle difference in terminology  :-)

--"J"

_______________________________________________
Openal-devel mailing list
[hidden email]
http://opensource.creative.com/mailman/listinfo/openal-devel
Reply | Threaded
Open this post in threaded view
|

Re: AL_SOFT_direct_channels

Chris Robinson-5
On Saturday, March 03, 2012 1:51:00 AM Jason Daly wrote:
> OK, I get it now.  Subtle difference in terminology  :-)

How's this version?

Name

    AL_SOFT_direct_channels

Contributors

    Chris Robinson

Contact

    Chris Robinson (chris.kcat 'at' gmail.com)

Status

    In-progress

Dependancies

    This extension is written against the OpenAL 1.1 specification.

Overview

    This extension allows a multi-channel source to play without virtualized
    output speakers. By default, OpenAL requires buffer channels to be down-
    mixed to the output channel configuration, possibly using HRTF techniques
    to give a sense of speakers that may not be physically present. Sometimes
    audio tracks are authored with their own spatialization effects, where the
    AL's virtualization methods can cause a notable decrease in audio quality.

    This extension provides a mechanism for applications to specify whether
    audio should be filtered according to the AL's channel virtualization
    rules for multi-channel buffers.

Issues

    Q: Should this be a buffer property or source property?
    A: Source property. This gives more flexibility to the app to decide
       whether some piece of audio should be filtered or not.

    Q: Should this work on mono (3D) sources?
    A: No. Besides most people not having a mono speaker, or possibly even a
       front-center speaker, its main intent is for stereo tracks that have
       spatialization effects pre-applied.

    Q: Are environmental effects, provided by EFX for example, still applied?
    A: Yes. There's no compelling reason to disable them, particularly when
       the application has to enable them on a per-source basis in the first
       place.

New Procedures and Functions

    None.

New Tokens

    Accepted by the <paramName> parameter of alSourcei, alSourceiv,
    alGetSourcei, and alGetSourceiv:

        AL_DIRECT_CHANNELS_SOFT                  0x1033

Additions to Specification

    Append to Section 4.3.2, Source Attributes

    Table 4.x Channel Virtualization

    Name                       Signature  Values               Default
    -------------------------  ---------  -------------------  ----------
    AL_DIRECT_CHANNELS_SOFT    i, iv      AL_TRUE, AL_FALSE    AL_FALSE

    Description:
    AL_DIRECT_CHANNELS_SOFT set to AL_TRUE indicates the audio channels are
    not virtualized and play directly on the matching output channels if they
    exist, otherwise they are dropped. Applies only when playing non-mono
    buffers.

_______________________________________________
Openal-devel mailing list
[hidden email]
http://opensource.creative.com/mailman/listinfo/openal-devel