Le 01/04/2016 18:33, Jean Aunis a écrit :
Le 01/04/2016 14:00, Joshua Colp a écrit :
<snip>
I think this is fine, provided there is still some high ceiling
value. Allowing a queue to potentially grow out of control would be bad.
I think if we were able to switch things to using a timer instead we
could actually get rid of this synchronization. It exists because it
has to bring together two directions and then provide the media.
I also don't see your review on gerrit. Java (yay Java!) ran out of
memory somewhat overnight it seems and I've restarted gerrit this
morning. That may have caused the review to not actually get
submitted. If you do so again it should work fine and if not we can
help figure out why.
Cheers,
I could add a constant AST_AUDIOHOOK_LONG_QUEUE set to 500 ms or
another value, and flush the queues if they exceed this value,
whatever the flags set on the audiohook.
By the way, shouldn't the audiohook be created with the flag
AST_AUDIOHOOK_MUTE_WRITE if the option "o" is set ? It is not the case
for the moment, and thus we are feeding the write factory with frames
which will never be read.
I have just updated the review with these two modifications:
- setting AST_AUDIOHOOK_MUTE_WRITE if required
- checking against a constant AST_AUDIOHOOK_LONG_QUEUE in audiohook.c to
prevent the queues from growing out of control
Best regards,
Jean Aunis
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
