ConfigExtensionsItf and object lifetime

Section 3.1.1 of the provisional AL specification describes the different states of OpenMAX AL objects. Specifically it says:

Unrealized (initial state): The object is alive but has not allocated resources. It is
not yet usable; its interfaces’ methods cannot yet be called.

This means the application would have to create an object first using the engine and then call Realize on its object interface to be able to query some object-specific interfaces. I guess that the ConfigExtensionsItf can also not be used until the object has reached the Realized state.

So, let’s assume I have some implementation of OpenMAX AL which needs to allocate resources for some objects that are not covered by the specification. Without those resources the object would not be able to work properly (or not work at all). So, I would expect from the application to set some key-value pairs via the ConfigExtensionsItf for the object to initialize itself correctly.

How could this problem be solved? One idea would be to (mis-)use the engine’s ConfigExtensionsItf before creating the object in question. Another would be to initialize the object with some default values nevertheless, although it would be quite useless from the application’s view, but then again I think this would make the application more portable.

Any suggestions how to solve this? Or did I even misunderstand the usage of the ConfigExtensionsItf?

Yes, this is correct. You cannot use GetInterface to get the ConfigExtensionsItf instance before the object has been realized.

There will be a new method for vendor-specific object’s creation in XAEngineItf in the final 1.0 version of the OpenMAX AL spec: CreateExtensionObject. This method has a void-pointer parameter pParameters which will enable the application to give any vendor-specific parameters to the new vendor-specific object. The final 1.0 version of the spec will be published this summer.

Yes, this is another option.

Best regards,
Matti