[Openal] help
chengann
chengann at edslab.com
Tue Nov 27 14:34:53 PST 2007
help
----------------------------------------
From: openal-request at opensource.creative.com
Sent: Wednesday, November 28, 2007 4:01 AM
To: openal at opensource.creative.com
Subject: Openal Digest, Vol 20, Issue 11
Send Openal mailing list submissions to
openal at opensource.creative.com
To subscribe or unsubscribe via the World Wide Web, visit
http://opensource.creative.com/mailman/listinfo/openal
or, via email, send a message with subject or body 'help' to
openal-request at opensource.creative.com
You can reach the person managing the list at
openal-owner at opensource.creative.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Openal digest..."
Today's Topics:
1. Re: Multiple local players (Daniel PEACOCK)
2. Re: AL error states and threads (Daniel PEACOCK)
3. Re: AL error states and threads (Chris Robinson)
----------------------------------------------------------------------
Message: 1
Date: Mon, 26 Nov 2007 13:00:02 -0800
From: Daniel PEACOCK
Subject: Re: [Openal] Multiple local players
To: openal at opensource.creative.com
Message-ID:
Content-Type: text/plain; charset=US-ASCII
Multiple Contexts on a single Device are not well supported in Creative's
OpenAL implementations - so should probably be avoided unless you ship your
own 'known' OpenAL implementation.
I think Buffers technically belong to a Device so you can't share Buffers
across multiple Devices.
This means supporting multiple Listeners (on a single Context & Device)
requires some work on the application side. Assuming you want to have all
the sound effects "heard" by both Listeners you will need to play each
sound each 2 different Sources (they can share the same audio sample data,
stored in an AL Buffer). One of the Listeners can be represented by the
AL Listener and all it's sound effect positions can be passed to AL "as
is". Sound effects for the other game Listener will need to have their 3D
positions rotated and translated based on the position and orientation of
the two listeners. It would be worth having a cut-off point where
sound-effects are no longer heard by a Listener.
Dan
Notice
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying or distribution of the message, or
any action taken by you in reliance on it, is prohibited and may be
unlawful. If you have received this message in error, please delete it
and contact the sender immediately. Thank you.
Chris Robinson
.com> To
Sent by: openal at opensource.creative.com
openal-bounces at op cc
ensource.creative
.com Subject
Re: [Openal] Multiple local players
11/24/2007 01:22
PM
On Saturday 24 November 2007 12:30:55 pm Charles Pence wrote:
> What's the potential overhead for this look like? It would seem that
> I'd be loading each buffer into both contexts, keeping a full set of
> sources for both contexts, and manipulating them identically through
> some sort of a wrapper layer (presumably both at around 70% volume to
> prevent clipping?). How much RAM would that eat up, assuming some
> reasonable number of buffers/sources for a small-ish game (maybe 40 or
> 50 buffers, tops, and maybe sixteen sources/channels per context)?
As far as OpenAL Soft is concerned, sources don't take up much memory (a
bit
over 100 bytes each), and buffers can be shared between devices. However,
in
a hardware environment (eg. with Creative's drivers using accelerated
DirectSound), sources in one context can reduce the number of sources
available for the other context (since you have limitted hardware voices,
which may be taken when the source is created, when a buffer is attached to
it, or when it's played).
I'm also not sure if the spec allows for sharing buffers across devices.
Sources are per-context, but I'm having trouble finding where the spec
mentions the scope of buffers (per-device or global). Hopefully someone
with
more knowledge can say.
_______________________________________________
Openal mailing list
Openal at opensource.creative.com
http://opensource.creative.com/mailman/listinfo/openal
ForwardSourceID:NT000525FA
------------------------------
Message: 2
Date: Mon, 26 Nov 2007 13:19:40 -0800
From: Daniel PEACOCK
Subject: Re: [Openal] AL error states and threads
To: Brian Meidell Andersen
Cc: openal at opensource.creative.com
Message-ID:
Content-Type: text/plain; charset=US-ASCII
Hi Brian,
I agree that this is something which should be addressed in the future.
As for OpenGL ... I could be wrong here, but I thought the same problem
existed there, and the only solution was to use multiple Contexts?
Dan
Creative Labs, Inc.
Notice
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying or distribution of the message, or
any action taken by you in reliance on it, is prohibited and may be
unlawful. If you have received this message in error, please delete it
and contact the sender immediately. Thank you.
Brian Meidell
Andersen
on.com> openal at opensource.creative.com
Sent by: cc
openal-bounces at op
ensource.creative Subject
.com Re: [Openal] AL error states and
threads
11/26/2007 11:26
AM
Thanks for the answer!
I've already solved the problem that I was having, but wouldn't it be a
good idea to change this in the spec and implementation for the future?
Reasons:
1) It's what OpenGL does
2) It would make it possible to follow the recommended alGetError()...
alWhateverCall()... alGetError() flow, without the need to mutex every
single OpenAL call set
3) I have a hard time thinking of any drawbacks, beyond the fact that
someone needs to implement the change.
The fact that the error state is not stored per thread right now, makes
the fact that OpenAL is thread safe an almost moot point if you want to
implement error checking in your program, since you need to litter your
code with mutexes around every alGetError/alWhateverCall/alGetError set
anyway.
Just a thought.
/Brian
Daniel PEACOCK wrote:
>
> Hi Brian,
>
> >> If I have two threads, A and B, does a bad alSomething
> >> call on thread A return an error for alGetError in thread B?
>
> Unfortunately the answer is "yes" because the error is stored
> per-Context. This is one of the downsides to have function calls that
> don't return error codes.
>
> Dan
> Creative Labs, Inc.
>
> ourceID:NT000522FA
_______________________________________________
Openal mailing list
Openal at opensource.creative.com
http://opensource.creative.com/mailman/listinfo/openal
ForwardSourceID:NT00052786
------------------------------
Message: 3
Date: Mon, 26 Nov 2007 14:06:22 -0800
From: Chris Robinson
Subject: Re: [Openal] AL error states and threads
To: openal at opensource.creative.com
Message-ID: <200711261406.22753.chris.kcat at gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Monday 26 November 2007 01:19:40 pm Daniel PEACOCK wrote:
> As for OpenGL ... I could be wrong here, but I thought the same problem
> existed there, and the only solution was to use multiple Contexts?
In OpenGL, contexts are set per-thread and can't be current in multiple
threads at the same time, so an error generated in one context can never be
seen in another thread without explicit context switches at both ends. Unlike
OpenAL where contexts are set per-process.
------------------------------
_______________________________________________
Openal mailing list
Openal at opensource.creative.com
http://opensource.creative.com/mailman/listinfo/openal
End of Openal Digest, Vol 20, Issue 11
**************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://opensource.creative.com/pipermail/openal/attachments/20071127/df6fdbd0/attachment.html
More information about the Openal
mailing list