OpenSLES and SL_DATALOCATOR_ADDRESS

531 views
Skip to first unread message

simons....@gmail.com

unread,
Feb 22, 2011, 11:04:29 AM2/22/11
to andro...@googlegroups.com
when I try to create the audioplayer with SLDataLocator_Address i get an error
02-22 16:43:26.095: ERROR/libOpenSLES(8180): Cannot create audio player with data locator type 0x2

here is my code
    /* configure audio source */
    SLDataLocator_Address loc_addr = {SL_DATALOCATOR_ADDRESS, _pstSample->pBuffer, _pstSample->u32BufferSize};
    SLDataFormat_PCM format_pcm = {SL_DATAFORMAT_PCM, _pstSample->u32ChannelNumber, _pstSample->u32SampleRate,
        SL_PCMSAMPLEFORMAT_FIXED_16, SL_PCMSAMPLEFORMAT_FIXED_16,
        SL_SPEAKER_FRONT_CENTER, SL_BYTEORDER_LITTLEENDIAN};
    SLDataSource audioSrc = {&loc_addr, &format_pcm};

    // configure audio sink
    SLDataLocator_OutputMix loc_outmix = {SL_DATALOCATOR_OUTPUTMIX, sstSoundSystem.outputMixObject};
    SLDataSink audioSnk = {&loc_outmix, NULL};

    // create audio player
    const SLInterfaceID ids[1] = {SL_IID_SEEK};
    const SLboolean req[1] = {SL_BOOLEAN_TRUE};
    result = (*sstSoundSystem.engineEngine)->CreateAudioPlayer(sstSoundSystem.engineEngine, &pstResult->PlayerObject, &audioSrc,
            &audioSnk, 1, ids, req); <------------------ it fails here ------------------->
    orxASSERT(SL_RESULT_SUCCESS == result);

is this a supported android feature?

TIA

Philippe

Glenn Kasten

unread,
Feb 23, 2011, 10:39:45 AM2/23/11
to android-ndk
See docs/opensles/index.html section "Objects and interfaces", the
last 4 rows for data locators.

On Feb 22, 8:04 am, "simons.phili...@gmail.com"

simons....@gmail.com

unread,
Feb 24, 2011, 5:34:54 AM2/24/11
to andro...@googlegroups.com
crap !

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.


Alan deLespinasse

unread,
Apr 2, 2014, 3:45:48 PM4/2/14
to andro...@googlegroups.com
I think I'm having the same problem (3 years later), although the error log message is now "Source data locator 0x2 not supported with SL_DATALOCATOR_OUTPUTMIX sink".

I'm not totally sure I'm interpreting the table in docs/opensles/index.html correctly. It looks like the columns are OpenSL ES objects and the rows are interfaces, EXCEPT that the last four lines are data locator types... is that correct?

The absence of a line for DataLocator_Address then implies that that isn't supported at all, right? The error message implied to me that it was just unsupported with an OutputMix as the sink, like maybe it would work with other sinks... but now I don't think so.

Alan deLespinasse

unread,
Apr 7, 2014, 7:36:38 PM4/7/14
to andro...@googlegroups.com
I was able to work around this by using buffer queues instead. You don't even have to register callbacks on them or keep the queues full. Once a buffer queue player is in the "play" state, enqueueing a buffer makes it start playing, and running out of buffers makes it stop playing. It's almost the same functionality as the address-based players that are apparently unimplemented.

Each time my game needs to play a sound, it takes a player from a pool that I've created in advance, clears it, then enqueues the sound. Clearing makes it so that the newly queued sound will play right away, instead of waiting for then end of the buffer it is currently playing.

Originally I was doing stop + clear + play + enqueue each time instead of just clear + enqueue, but that was making it crash occasionally. It looked like maybe a race condition. Anyway it turned out to be unnecessary.

For best utilization of a pool of players, you would look for one that is not currently playing anything (you could skip the clear operation then, unless there are none available and you decide to use one that is currently playing a buffer). I'm not even bothering with that; I just cycle through the players in order, always using the least recently used one, and I clear it just in case.
Reply all
Reply to author
Forward
0 new messages