Re: OpenSL and mixing of PCM sources ...

[Glenn Kasten]

You mention destroying the [buffer] queue. That doesn't sound right ... the buffer queue is an interface, not an object, so it should not be destroyed.  Destroying the player object will also release all associated interfaces including the buffer queue interface.

The Android implementation of OpenSL ES only supports a single engine object per app; see paragraph 2 of section "Platform configuration" of $NDK/docs/opensles/index.html

It is permitted, but unusual to use so many buffers. Why do you need them? Having that many buffers enqueued could increase your latency, as each new enqueue has to wait for all the previous ones to play before it is played.

On Friday, July 13, 2012 4:03:01 PM UTC-7, Glennward Turtle wrote:

I have an implementation that will open a complete set of the engine, player, and queue objects per PCM output stream I wish to support.  My first question is will these independent engine instances mix?  I assume they will, but I've had a hard time finding anything in the documents to confirm this.  My second question has to do with the SIGSEGV I encounter when shutting down even just one set of the engine objects.  I tend to do this within the last queue callback itself, and of course, clear the queue first to ensure no more callbacks.  I then Destroy() the queue, player, and engine objects in that order.  At some later time, I encounter the SIGSEGV within the callback thread within the android::audioTrack::processAudioBuffer(sp?) method.  The NDK samples seem to not instantiate, destroy, and instantiate again, and thus don't offer me much of an example.  Is this a proper usage pattern, and will these engine instances (assuming they don't crash) cooperatively mix?

Also, I create an audio source specifying up to 32 buffers to be queued at one time.  Most examples I've seen work with one or two.  Is this a limitation?  I can certainly create the buffer queue and all seems to work fine until after I shut the engine down ...