AudioRecordQueue behaves incorrectly with no input

h4yn0nnym0u5e

Well-known member
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
 
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
 
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.
 
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..."
 
Back
Top