[Openal-devel] Ownership and lifetime issues

[Jason Daly]

Disclaimer...

The comments below are based entirely on my current understanding, and 
not any recent, thorough reading of the spec, so take them as such.


Sven Panne wrote:

>Listeners
>=========
>
>* There is always exactly one listener per context.
>
>* A listener can neither be created nor destroyed, as its lifetime is
>  identical to the context it belongs to.
>  
>
Agree with that.

>
>Sources
>=======
>
>* There can be arbitrary many sources per context.
>
>* Every source is associated with exactly one context for its whole
>  lifetime, i.e. a source's context remains constant after the source
>  is created.
>
>* Sources must be explicitly created and destroyed.
>
>* Sources are not automatically destroyed when their context is
>  destroyed, i.e. sources are not "owned" by a context.
>
>* One can have "dangling sources", i.e. sources where their associated
>  context has already been destroyed.
>
>
>  
>
Implementations are free to limit the number of available sources.  With 
the portable module there is currently no limit.  I never thought about 
the context/source relationship, as I always just clean up the sources 
before destroying the context.  I certainly wouldn't expect to be able 
to use any sources after the associated context is destroyed.


>Buffers
>=======
>
>* Buffers can be shared between contexts of the same device, but not
>  between contexts of different devices.
>---------------
>
>INTERPRETATION 1 OF THE SPEC:
>
>* Buffers can have exactly zero or one associated device.
>
>* Initially there is no device associated with a buffer, and the
>  device is set when the first source references a buffer to the
>  device of the context of the source.
>
>---------------
>
>INTERPRETATION 2 OF THE SPEC: 
>
>* Buffers have always exactly one associated device.
>
>* The device associated with a buffer is the device of the current
>  context when alGenBuffers is called.
>
>---------------
>  
>

Never even considered this question...  I'd think 2 would be a better 
choice for an implementation.


>* If there is an associated device for a buffer, it remains constant.
>
>* Buffers must be explicitly created and destroyed.
>
>* Buffers are not automatically destroyed when their device is closed,
>  i.e. buffers are not "owned" by a device.
>
>* One can have "dangling buffers", i.e. buffers where their associated
>  device has already been closed.
>
>* A buffer can be referenced by arbitrary many sources which are
>  associated with the same device as the buffer.
>  
>

Agree with those.


>* What happens when buffers are destroyed which are already queued?
>  
>

"Undefined behavior (tm)"  :-)


>Devices
>=======
>
>* There can be arbitrary many open devices at the same time.
>
>* There can be several devices with the same name open at the same
>  time.
>
>* ALC errors are recorded per-device, and if there is no unambiguous
>  device available, a boolean return value is used.
>
>* Capture devices are special in the sense that no contexts at all are
>  associated with them, and they posess no error state. The notion of
>  "current context" is irrelevant for anything capture-related.
>  
>

Sounds right.  It seems that capture devices should have an error state, 
doesn't it?


>
>Contexts
>========
>
>* Each context is associated with exactly one device.
>
>* The device associated with a context remains constant.
>
>* Sources must be explicitly created and destroyed.
>
>* Contexts are not automatically destroyed when their device is
>  closed, i.e. contexts are not "owned" by a device.
>
>* One can have "dangling contexts", i.e. contexts where their
>  associated device has already been closed.
>
>* Each context can have different attributes which are specified at
>  context creation time and remain constant.
>
>* There is either no current context or exactly one current context
>  for all of OpenAL, i.e. the notion of "current context" is global.
>
>* Making a context current or not has nothing to do with the
>  processing of the context itself, it only changes an implicit
>  parameter to most AL functions, i.e. the current context is a global
>  variable for the whole program controlled via alcMakeContextCurrent.
>
>* Multiple contexts on multiple devices can produce sound at the same
>  time.
>
>* AL errors are recorded per-context.
>  
>

Agree with this.


>
>alCaptureInit_EXT and friends
>=============================
>
>INTERPRETATION 1 OF THE CODE:
>
>* The Linux-specific alCaptureInit_EXT family of functions is
>  different from the official capture API in the sense that the
>  current context can be extended by a potential capturing facility.
>
>* All alCaptureFOO_EXT functions use the capturing facility of the
>  current context (if there is one).
>
>* There can be more than one capturing facility active at any point in
>  time.
>---------------
>
>INTERPRETATION 2 OF THE CODE:
>
>* The Linux-specific alCaptureInit_EXT family of functions offers a
>  single, global capturing facility, i.e. there is always no capturing
>  facility available or exactly one.
>
>* All alCaptureFOO_EXT functions use the global capturing facility (if
>  there is one).
>
>---------------
>
>  
>

The original capture features were called AL_EXT_capture, and there was at one point a (crude) document for it.  I'm pretty sure the original authors didn't really entertain the question you pose.  Most likely, interpretation 2 is the more correct one.  I'd be really surprised if you can start a capture on one device, change contexts, and then start one on a different device.  I'd be even more surprised if you could do it between contexts on the same device.



-- 

--"J"

"I'm a castaway stranded in a desolate land,
 I can see the footprints in the virtual sand."
	--Neil Peart