Adding new Effects

Hi Erik

The OpenSL document specifies Interfaces for audio effects such as equalizer, bass boost, preset reverberation, stereo widening etc. OpenSL ES supports bass boost via SLBassBoostItf. I need to introduce a vendor-IP audio effect.

(a)Can I introduce a new structure specific to the new audio effect. For Ex. BassBoost is supported through the structure SLBassBoostItf with a specified set of functions. If I have an audio effect " AudioEnhancement". Can I add an interface " SLAudioEnhancementItf " as follows

struct SLAudioEnhancementItf_ {

SLresult (*SetBassGain)(
SLAudioEnhancementItf self,
SLpermille strength
);
SLresult (*SetAudioGain)(
SLAudioEnhancementItf self,
SLpermille strength
);
SLresult (*SetSurroundGain)(
SLAudioEnhancementItf self,
SLpermille strength
);
SLresult (*SetEnabled)(
SLAudioEnhancementItf self,
SLboolean enabled
);
SLresult (*IsEnabled)(
SLAudioEnhancementItf self,
SLboolean *pEnabled
);
};

(b)Or can I modify the current SLBassBoostItf to accommodate the interfaces i require.
©Or do I derive from the existing SLBassBoostItf.

Thanks
Simi

Hi Simi,

I’m sure you have read Section 3.6 of the OpenSL ES 1.1 specification which talks about extensibility and how to extend the API. Your proposed interface (a) is an excellent way to extend the API with the functionality that you are describing. It is not possible to extend an existing interface by adding methods to it (b) as an application would not be able to know which version of the interface it has received. © is also a possibility - to create a new interface which is derived from the existing SLBassBoostItf interface. The new interface would then have a new IID and both interfaces would be available to the application. In the end, it is the extension designer’s preference whether to use (a) or ©.

For the name of your interface, I suggest you take a look at section 3.6.9 Avoiding Naming Collisions. In order to avoid naming collisions, it is recommended that you add either your vendor name or an abbreviation thereof after the SL and before the interface name in the name of the interface: SLAcmeDistortionItf (where Acme is the name of the vendor). This avoids naming collisions with other vendor extensions and with future versions of the API.

In general, I would recommend being as specific as possible in naming your interface in order to make it easier for an application developer to know exactly what the interface does and to avoid future naming conflicts.

I would also recommend that for every Set() method you have a corresponding Get() method. We do this as standard practice in the specification, and following the same practice when designing your extension interfaces makes them consistent with the specification and easier to use.

Best,

Erik