vicidial.org

Hi,
Hoping someone can shine some light on this for me:
I am currently running VERSION: 2.0.5-174, when my agents are on a call there appears to be a delay between them speaking and the person they have called hearing what has been said (a couple of secs) and the same thing occurs the other way around i.e a delay between the person that has been called speaking and the agent hearing what they have said. The result of this is conversations clashing and confusion. The agent will say something, wait for a response and maybe start to talk again, when talking again the response starts to come in and both parties are talking over the top of eachother. The agents do not want to use the dialer while this is going on. I had a Sangoma USB timer device installed on my box and am wondering if the settings on this could be the culpret (Not 100% sure what it does) or is it something simple that can be changed via Managers loggin. Upload speed on the server is about 2mb if that helps.
I would be really greatful if anyone could help with this.
Regards
CJ.

https://issues.asterisk.org/view.php?id=3599

could it be this?

I've been doing some experiments with app_meetme, and only have SIP phones here to play with. I have been finding issues with audio delay that I think may be to do with the use of pseudo channels to conference non-Zap channels.

I don't know whether the same issue applies to direct Zap channels or not.

The easiest way to demonstrate it is first of all to make a pair of calls from SIP phones to an extension that calls MeetMe(2222|). Speaking into both phones and listening to them both gives an audio delay of about 300-400ms.

Then repeat the experiment using MeetMe(2222|q). This time the audio comes back almost instantaneously.

I suspect that the problem is something to do with the conf_play() of the enter and leave sounds. My guess is that by writing that raw data into the pseudo device fd, it causes a backlog that never drains, because the device is only getting emptied at the same rate as the conference is
filling it.

The delay does seem to be of approximately the same length as the enter sound.

To test this theory, I commented out the call to careful_write() in conf_play(). Having done this, the delay was not present, even when not using the 'q' flag.

My first attempt to fix this was not successful. I think it made an improvement, but it certainly did not eliminate the delay. The idea of the attempt was to count the number of bytes written to the pseudo-fd by conf_play(), and then to skip that number of bytes when relaying voice frames to that pseudo-fd. I've attached the patch to illustrate what I was trying, but it is NOT a solution. I think my understanding of the mechanism is still lacking.