Results 1 to 6 of 6

Thread: Buffer sizes in OpenSL ES

  1. #1
    Junior Member
    Join Date
    Jan 2017
    Posts
    3

    Question Buffer sizes in OpenSL ES

    Hi all,

    I'm looking at doing a C++ implementation for OpenSL ES, and need to get hold of possible buffer sizes to use (for the enqueued buffers), i.e. I don't want to use JNI for accessing
    properties like "android media property OUTPUT_FRAMES_PER_BUFFER".

    For sample rates, I suppose I can use SLAudioInputDescriptor and SLAudioOutputDescriptor to get available rates, and then use 48000 as default rate (as it is a required rate in Android).

    But how can I get hold of the default and possible buffer sizes ?? Or do I even need to care ?

    Regards
    Robert

  2. #2
    Super Moderator
    Join Date
    Mar 2009
    Location
    Sweden
    Posts
    64
    Hi Robert,

    The buffer size has little to do with the content of the buffer. The reason for having multiple buffers is so that you don't have to allocate the memory all in one big chunk. In general, pick a buffer size that is suitable to the application and the content being played. The implementation will process the buffers one by one and release them when it's done with them.

    So to answer your question - do you care: Yes, you do care. But it is not critical and will not affect playback. Too small of a buffer means you will constantly be filling and submitting them. Too large of a buffer and you may run into memory allocation issues, or your entire content will end up in a single buffer.
    Erik Noreke,
    Working Group Chair OpenSL ES, OpenMAX AL and Safety Critical

  3. #3
    Junior Member
    Join Date
    Jan 2017
    Posts
    3
    Quote Originally Posted by Erik View Post
    So to answer your question - do you care: Yes, you do care. But it is not critical and will not affect playback. Too small of a buffer means you will constantly be filling and submitting them. Too large of a buffer and you may run into memory allocation issues, or your entire content will end up in a single buffer.
    Thanks Erik, that was pretty much what I've come to expect from reading the documentation.

    The main reason I asked is because of wanting to have minimal latency. Example: if I use a Nexus 6 device, it has a native buffer size (for ALSA) of 192 samples. So in this case the ideal thing would be to use that buffer size with OpenSL. With any other buffer size, the OpenSL implementation will have to wrap it somehow to compensate for the difference in sizes, thereby inevitably adding to the total latency.

    But I think I can manage right now using a buffer size defined in the application.

  4. #4
    Junior Member
    Join Date
    Jan 2017
    Posts
    3
    Quote Originally Posted by robiwan View Post
    Example: if I use a Nexus 6 device, it has a native buffer size (for ALSA) of 192 samples. So in this case the ideal thing would be to use that buffer size with OpenSL. With any other buffer size, the OpenSL implementation will have to wrap it somehow to compensate for the difference in sizes, thereby inevitably adding to the total latency.
    So, the question now is if this is anything that is considered for OpenSL ES ? I.e. the possibility to get hold of the underlying subsystem buffer size ? Right now, on Android, to get minimal latency, one needs to query Android property "android.media.property.OUTPUT_FRAMES_PER_BUFF ER" and then choose that size + 2 buffers in the queue. Ideally the need to query Android (via JNI) should be avoided.

  5. #5
    Newbie
    Join Date
    May 2017
    Posts
    1
    Quote Originally Posted by robiwan View Post
    Thanks Erik, that was pretty much what I've come to expect from reading the documentation.

    The main reason I asked is because of wanting to have minimal latency. Example: if I use a Nexus 6 device, it has a native buffer size (for ALSA) of 192 samples. So in this case the ideal thing would be to use that buffer size with OpenSL. With any other buffer size, the OpenSL implementation will have to wrap it somehow to compensate for the difference in sizes, thereby inevitably adding to the total latency.

    But I think I can manage right now using a buffer size defined in the application.
    Why is it that 192 seems to be the accepted buffer size (i.e. on Pixel XL phone), but other phones which have problems with audio have a much higher buffer size of 8305 (i.e. Samsung Galaxy S4)?

  6. #6
    Junior Member
    Join Date
    Dec 2016
    Posts
    6
    Too large of a buffer and you may run into memory allocation issues, or your entire content will end up in a single buffer.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Proudly hosted by Digital Ocean