Jean Aunis wrote:
Hello,
As described in the issue ASTERISK-25866
<https://issues.asterisk.org/jira/browse/ASTERISK-25866>, it appears
that ChanSpy is randomly loosing audio frames, because it sets the flags
AST_AUDIOHOOK_TRIGGER_SYNC and AST_AUDIOHOOK_SMALL_QUEUE when creating
the audiohook: these option cause the audiohook's queue to be flushed of
"old" frames at very short intervals.
I have submitted a patch on gerrit which does two things :
1- do not set the flag AST_AUDIOHOOK_TRIGGER_SYNC if ChanSpy has been
called with the option "o": in this case we only listen to the audio
coming from this channel so this flag is useless
2- create a new option "l" which prevents the flag
AST_AUDIOHOOK_SMALL_QUEUE from being set. I find it better than just
removing the flag in all cases, because this may introduce some delay in
the audio, which may not be acceptable for many ChanSpy users.
What do you think of the idea ?
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,
--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
--
_____________________________________________________________________
-- 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
