Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 4 of 4

Thread: AudioRecordQueue behaves incorrectly with no input

  1. #1
    Senior Member
    Join Date
    Apr 2021
    Location
    Cambridgeshire, UK
    Posts
    117

    AudioRecordQueue behaves incorrectly with no input

    The Audio library design rules state that a NULL received audio block (from receiveReadOnly()) should be treated as if a silent block had been received. AudioRecordQueue does not do this, but simply fails to count or queue the NULL, even when it has been enabled by queue.begin(). There seem to be three possible fixes:
    • queue the NULL, and change the API documentation to state that if AudioRecordQueue::available() reports a non-zero number, then when AudioRecordQueue::readBuffer() returns NULL this should be interpreted as a silent block: AudioRecordQueue::freeBuffer() can still safely be called, and the behaviour will be consistent
    • queue a "flag" value, e.g. 1 (invalid but non-zero "pointer"); interpret AudioRecordQueue::readBuffer() == 1 as silent block; modify AudioRecordQueue::freeBuffer() so it does not attempt to release() the invalid block pointer
    • allocate and zero out an audio block from the pool, and queue that as normal

    The first option would be a problem for existing code that never calls AudioRecordQueue::available() and relies on AudioRecordQueue::readBuffer() returning non-NULL values to empty the queue: the queue could fill without limit. The second option would be a problem for existing code when it tries to de-reference the invalid pointer. The third option uses more memory and CPU.

    Cheers

    Jonathan

  2. #2
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,054
    depends.
    Whatver the queue can do here is wrong in the one or other situation.
    Better is to make sure it does not get NULL

  3. #3
    Senior Member
    Join Date
    Apr 2021
    Location
    Cambridgeshire, UK
    Posts
    117
    Well, it's certainly wrong now...

    I'm inclined to agree with you that returning NULL to mean "silence" is probably also the Wrong Thing, due to the clash with the existing documented behaviour of AudioRecordQueue::readBuffer(), so we should choose option 3. Easier to deal with at the application level, too.

  4. #4
    Senior Member
    Join Date
    Apr 2021
    Location
    Cambridgeshire, UK
    Posts
    117
    Issue created and PR submitted. Also "fixed" returning NULL on a second call to ::readBuffer() without an intervening ::freeBuffer(), as NULL is documented as "no data available", not "either no data available or you need to call freeBuffer, depending..."

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •