Summary:ASTERISK-03519: Audio delay in MeetMe using SIP when not 'q' mode
Reporter:Tony Mountifield (softins)Labels:
Date Opened:2005-02-15 05:17:23.000-0600Date Closed:2008-01-15 15:55:01.000-0600
Versions:Frequency of
Environment:Attachments:( 0) app_meetme-head-try1.diff
( 1) app_meetme-head-v2.diff
( 2) app_meetme-head-v3.diff
( 3) app_meetme-stable-v2.diff
( 4) Asterisk_MeetMe_Delay_Issue.rtf
( 5) mydiff.txt
( 6) starmenufix.txt
( 7) app_meetme-head-v4.diff
Description: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.


Disclaimer on file.
Comments:By: Tony Mountifield (softins) 2005-02-15 06:34:06.000-0600

OK, that first attempt at a solution is completely wrong. I was getting confused between the conference pseudo fd and the channel pseudo fd. Any improvement was probably just wishful thinking.

By: Tony Mountifield (softins) 2005-02-15 11:13:54.000-0600

Now found a much better fix which does seem to work properly. The problem is that the careful_write() to conf->fd blocks in real-time (enter takes 279ms and leave takes 179ms). This delays the channel thread, which for non-Zap devices means the copying to or from the channel pseudo-fd is delayed. causing a backlog that is never cleared.

The fix is to spawn a thread for writing the enter and leave sounds. I've attached two patches: one for HEAD and one for Stable.

Note for bug marshall: please update summary field to include [patch]. Thanks!

By: Kevin P. Fleming (kpfleming) 2005-02-15 11:53:16.000-0600

I think this needs to be generalized a bit... there may be other sounds that need to be played to the channel, so maybe you should just create a new structure that takes the message information and the conference pointer, and have a generic "play message" function that you can invoke on a new thread.

By: Tony Mountifield (softins) 2005-02-15 12:16:01.000-0600

I do have a more generalised solution which is quite complex and is currently rather specific to my application. You need to have a queue of pending messages attached to the conference, because the whole point is to avoid blocking in the main loop, and yet to be able to concatenate announcements.

The objective of this specific fix was to correct the immediate problem in a very simple way, in both stable and head, so that a more general solution could be worked on for longer (to which I'll gladly contribute).

By: Kevin P. Fleming (kpfleming) 2005-02-15 12:34:39.000-0600

OK, then you need to get with anthm, bkw, moc and the others that are working on app_meetme2 design and make sure your input gets in the discussions :-)

Just keep in mind that there are some pending patches for app_meetme here in Mantis (announce number of users in conference is one) that will need to do what you are doing, and in that case the "enter" announcement consists of more than just a single file to be played.

By: Mark Spencer (markster) 2005-02-15 21:51:31.000-0600

Try latest CVS head.

By: Mark Spencer (markster) 2005-02-16 00:01:32.000-0600

Also, I do not believe this would qualify as MAJOR according to the bug guidelines given that the conferencing still does operate of course.

By: Tony Mountifield (softins) 2005-02-16 04:42:12.000-0600

Apologies, having re-read the guidelines, it should have been "minor".

The autoservice patch improves the specific issue, but not to the full extent. It still leaves more delay than when the 'q' flag is used. All it is doing is eating incoming frames while the careful_write() is blocked playing. careful_write() takes about 100ms less than the length of the sound being played, and this 100ms delay still remains. Also, the joining party only hears the last 100ms of the enter sound.

IMHO the correct solution is to play asynchronously, as per my v2 patch.

However, prompted by Kevin, I have generalized the solution to include playing files, and uploaded a v3 patch (HEAD only - I think the v2 patch should go into Stable).

Before doing so, I tested the 'i' flag (Intro User) and playing the join/leave announcements introduces a HUGE delay into the SIP channels, due to the use of ast_waitstream() in the main loop. My v3 patch uses the new conf_play() to play those announcements too, and they no longer introduce delay. It should be used any time an announcement is to be played to all users.

conf_play is used as follows:

conf_play(conf, ENTER, NULL); /* play standard enter sound */
conf_play(conf, LEAVE, NULL); /* play standard leave sound */
conf_play(conf, FILEKEEP, filename); /* play a file */
conf_play(conf, FILEDELETE, filename); /* play a file and delete when done */

The last option is used to tidy up the recorded user name.

I have not yet tested whether there is any interaction with the 'r' flag for recording the conference.

By: Mark Spencer (markster) 2005-02-16 11:04:47.000-0600

Your patch seems fine except that I think there may still be some issues with the cleanup process.

By: Tony Mountifield (softins) 2005-02-16 11:28:54.000-0600

Any issues in particular? I'd be happy for any advice.

Also, I think the same issue exists in other parts of Asterisk. I just found it in chan_agent too. I have two Budgetones next to each other. I did a call to AgentLogin from one of them. Then I did a call to Queue from the other. When the call was connected, I spoke into both phones at once. The audio came straight out of the Queue phone. It was delayed out of the AgentLogin phone. Commenting out the streaming of "beep" from chan_agent removed the delay.

By: Mark Spencer (markster) 2005-02-17 23:33:08.000-0600

Calling autoservice_start and _stop before and then after the beep should cause it to go away, is that what you're seeing?  Is there another thing going on where the autoservice isn't catching it?

By: Tony Mountifield (softins) 2005-02-18 01:50:23.000-0600

Thanks, I'll investigate the user of autoservice with agent beeps, and report any issues as a separate bug, so that this one doesn't get sidetracked from the original topic of playing meetme announcements asynchronously.

Any advice on the issues you think there might be with the cleanup process in my v3 patch?

By: Mark Spencer (markster) 2005-03-01 00:28:36.000-0600

Any update on whether the autoservice_stop and _start are enough to clear this up?

By: Tony Mountifield (softins) 2005-03-01 02:27:44.000-0600

This bug is about MeetMe issues, for which autoservice_stop and _start do not fix the issue, and for which an asynchronous playout facility is required. Please see again my bugnote above dated "02-16-05 04:42" and my v3 patch.

Mark, you said there may be cleanup issues with my patch, but didn't say what. Could you elaborate?

(I shouldn't have mentioned queues under this bug# - it has just sidetracked us from the main point)

By: Mark Spencer (markster) 2005-03-01 23:56:09.000-0600

There appears to be a race in the handling of the cleanup when there is a thread playing a sound and then you make the channel disappear / stop the audio in a different thread.

More importantly, I remain unconvinced that the autoservice is incapable of solving the problem and I want a real answer as to why you feel it cannot solve it.  Clearly autoservice will allow the channel to be immediately serviced, and drained of audio for the duration of when it's executing.  Assuming we immediately begin servicing it in the main thread, I see no way for things to get backed up.

By: Tony Mountifield (softins) 2005-03-03 03:42:00.000-0600

Mark, I'll take another close look for possible race conditions in the cleanup process.

Regarding why I believe autoservice is insufficient for this and why asynchronous playing is better and more general, I'll list the reaons below (some of these are repeats of what I've said above, 02-16-05 04:42, but I'll put them all in one place):

1. I timed the writes of the enter/leave sounds to the conf fd, and they consistently took about 100ms LESS than the actual duration of the sound to be played. Consequently, autoservice ran for 100ms less than required, and still left a residual backlog of 100ms delay in the pseudo-dev.

2. Using autoservice discards audio that could usefully be heard by the participant. With autoservice in conf_play, the entering party is prevented from starting the meetme loop and only hears the last 100ms of the enter sound. With asynchronous play, they enter the meetme loop immediately and hear the whole of the enter sound. This may sound trivial, but consider what happens if the enter sound is replaced with a meaningful announcement.

3. The asynchronous play technique allows the initiating of announcements from within the meetme loop too. In CVS-HEAD there are some new features (intro user) using ast_streamfile and ast_waitstream on the conference channel. The ast_waitstream calls play havoc with the SIP delay (and, I would guess, IAX or any other non-Zap channel). Calling autoservice is inappropriate in this situation, because it still stalls the meetme loop and consumes useful audio. My v3 patch replaces these ast_streamfile/ast_waitstream with calls to the new asynchronous conf_play, which allows the meetme loop to continue immediately and completely eliminates the introduction of this delay.

4. In your note of 02-16-05 11:04 you did say "your patch seems fine ...", but now seem less keen on it. Why? I hope my points above may convince you, and I'll certainly re-visit the cleanup process.

Anyone else tried this patch? Anyone have other comments?

By: Kevin P. Fleming (kpfleming) 2005-03-03 15:07:03.000-0600

This looks like it's ready to go to my eyes.

By: Mark Spencer (markster) 2005-03-03 17:36:17.000-0600

Please try lastest CVS head.  This should solve the problem as per our dev conf call.

By: Tony Mountifield (softins) 2005-03-04 03:21:44.000-0600

Mark, it does seem like you're ignoring the points I'm making.

Anyway, I've tried the conf_flush changes, and they don't make any difference, even after I corrected ioctl(fd,ZT_FLUSH,x) to ioctl(fd,ZT_FLUSH,&x)

This may be because the conf_flush call on the way in is before the conf_play of the enter sound.

In any case, the autoservice/flush approach appears to be addressing merely the original bug I reported and nothing else, whereas the asynchronous play technique not only fixes the original bug (instead of just covering it up), but also corrects meetme operation with the "intro user" flag *and* provides a valuable feature that can be used in other ways (thanks to Kevin for prompting me to generalize it).

By: Mark Spencer (markster) 2005-03-05 09:31:10.000-0600

Doh!  My notes from earlier didn't make it.  Thanks for catching the flush errors (double doh)...

Okay, so in summary:

1) Leaving 100ms of residual on the conference shared file descriptor is not important in any way, as the file descriptor we use for the individual channels is separated.

2) The value of the sound discarded during autoservice is very low given that if it were made available to the conference, it would collide with the sound from the announcement anyway and would presumably be unintelligible.

3) Fixing the flushing should eliminate the bug anyway.

By: Mark Spencer (markster) 2005-03-05 09:39:02.000-0600

And to answer the rest of your question...  Whenever I can avoid adding any additional complexity, especially new threads, I try to avoid it.  Keeping things simple, and working as much as possible with code that has actually been tested is much more practical for me.  

Anyway CVS now should do the flushing properly and at the proper time, please confirm that solves your problem.  Thanks!

By: Tony Mountifield (softins) 2005-03-08 16:28:03.000-0600

*sigh* /me bangs head against brick wall.

Now I know how bkw and anthm felt a few weeks ago :-(

I have just tried the latest HEAD app_meetme with the flush calls, and they still do not correct the problem. Meetme on non-Zap channels with the q flag starts with no delay on the channels, but removing the q flag brings the delays back. The i flag also introduces delays.

I still maintain asynchronous playing is the elegant way to solve this.

Regarding the potential race in the cleanup, the only thing I can see is that one thread calls ast_stopstream() while another is in ast_waitstream(). I thought that was legal. Is it? If not, what is the correct way for one thread to abort the stream being waited for by another thread? Everything else should be protected correctly by the mutex, e.g. emptying the queue, etc., and this only happens when the last user in a conference is exiting.

By: Brian West (bkw918) 2005-03-17 21:31:09.000-0600

Here you can use my wall if you like.. ;)


By: johnnyd (johnnyd) 2005-03-17 23:15:22.000-0600

I have done more tests on Meetme following comments from our users.The summary is that there definitely seems to be an issue with SIP channels in a conference whereby their voice transmission accumulates delays of up to 5-6 seconds in certain cases (independant of the network delays).

The attached file (rft format - sorry) has a series of measured results over a period of about one hour and shows the drift in the delay (up to 2 seconds). This severely impacts the usability of the conference function unfortunately.

I am happy to do some patching and testing but lack deep understanding of the * system to analyse the code.

By: Mark Spencer (markster) 2005-03-17 23:32:40.000-0600

No, it is not legal to ast_stopstream from another thread that is doing a waitstream.  Control is not being elegantly passed between the two threads.  Why is it you suspect the flushing is not clearing up the problem for you?  I will try to duplicate this problem.

By: johnnyd (johnnyd) 2005-03-18 00:55:32.000-0600

Following the previous information on the growing delay, I have applied, to CVS-head this time, the versions 3 patch posted by softins above and just concluded a one hour test of meetme in the same conditions as the document I posted here (1 SIp, 1 FXS, 1 IAX phone, all PCs on same LAN).

Clearly this time the delay was kept constant below 500ms, with in fact the IAX channel now being the "laggiest". The SIP sounds had 200ms delay maximum.

My conclusion: this patch is definitely improving that long delay issue as well.

Hope this helps.

By: Tony Mountifield (softins) 2005-03-18 02:22:26.000-0600

Johnny, what options were you passing to MeetMe in each case?

By: johnnyd (johnnyd) 2005-03-18 06:47:25.000-0600

I was using the M option only. I didn't try to add the 'q' option as I still want the joining/leaving sounds.

While I am on this subject, I noticed that with CVS head, the joining sound is either not present or just chopped off. The leaving sound is still played to the channels.

By: Tony Mountifield (softins) 2005-03-18 06:55:03.000-0600

Yes, without my async-play patch, the joiner of a conference hears only the tail end of their joining sound, but the existing participants hear all of it. This might not be true for real Zap channels.

By: johnnyd (johnnyd) 2005-03-18 07:32:58.000-0600

I will check on Monday when I am back in the office if this sound issue only applies to the joining party or all. Unfortunately, I had the impression that it was still present after applying your path, but I will confirm for each channel type.

My question now is: does this applies automatically to all sounds played when leaving temporarily the conference as well (like for meetme option 'a'), or is there more programming to cover all aspects?

Thanks for this useful patch.

By: () 2005-03-18 10:22:19.000-0600

I'm having the same problem while trying to setup a conferencing solution using SIP.  The calls come in on our gateways and then are handed off to asterisk to do the bridging.  The asterisk server (CVS-HEAD-03/18/05-11:02:28) is setup on fc2 with ztdummy.  The delay we experience seems to get progressively worse during the conference and makes the application unusable.  After awhile there is a good 5-8sec delay.  If it would help to look at our server, let me know.  I have toll free number mapped to the application for testing.  I'm available on irc.

By: johnnyd (johnnyd) 2005-03-18 16:28:34.000-0600


If you want, you can apply the patch version 3 above and test it. The two tests I have done (about 1 hour each) with and without a Zaptel channel indicates that the delay issue is at least contained (500ms maximum in my case).

There is a little manual editing required to apply the patch to current CVS-head as there has been some changes of app_meetme.c since then, but it is easy to find out where. I would be curious to see if you get the same results. Hope this helps.

By: kuj (kuj) 2005-03-22 20:50:36.000-0600


not related to the delay being discussed here, but rather to the conf flushing fix you put into CVS: ever since, users/admins get hung up on as soon as they try to access the "star menu". As soon as I back out the two ioctl's (and assorted code) as shown in uploaded starmenufix.txt, everything works fine again. The error message shown is

Mar 22 19:11:26 WARNING[6858]: app_meetme.c:1085 conf_run: Error setting conference
   -- Hungup 'Zap/pseudo-208065039'
 == Spawn extension (confline, 1234, 2) exited non-zero on 'SIP/2001-becd'

Can anybody else duplicate this? (Add an 's' to your conference options and press '*' while in a running conference.)

By: Donny Kavanagh (donnyk) 2005-03-24 10:13:35.000-0600

Whats the status here, is this resolved in CVS HEAD? or can you post a diff/patch for CVS HEAD?

By: doneill (doneill) 2005-03-24 12:10:03.000-0600

I am new to Asterisk and was directed to this bug report after posting a question in the Asterisk Users group.  I too am experiencing significant delays (up to multiple seconds) in the meetme conference not only in normal mode, but it quiet (q) mode too.  I downloaded a stable tarball of version 1.0.6.  I’m running multiple softphone clients, Firefly and SJphone, using both SIP and IAX protocols.  All direct SIP and IAX calls have negligible delays.  Calls within a meetme room have delays in excess of 500ms, up to several seconds.  I would like to try the latest patch, but it looks like it’s compared to previous patches.  Is it possible for the author to do a diff on app_meetme.c for version 1.0.6?  Thanks!  Also, if I’m still having audio delays with the ‘q’ mode enabled, will this patch help?

By: johnnyd (johnnyd) 2005-03-30 09:44:02.000-0600


I wanted to do the same thing, that is applying the patch to V1, but I soon realised that the list of new features it depends on is quite significant. The solution in my case, to avoid the latest CVS-head version which is not stable enough for production purposes, was to download the CVS-head version as of 17th of February, then apply the patch above. This has been stable enough to be used in production (at least with the features I use).

Use "cvs checkout -D February 17, 2005 zaptel libpri asterisk etc..."
Then apply the patch directly (no manual editing required as this cvs-head version includes the app_meetme.c file referenced in the patch, that is v1.80 of app_meetme.c).

Hope this helps. John.

By: Donny Kavanagh (donnyk) 2005-05-09 09:24:02

What is the status on this issue? with 1.0.7 i still notice lag in excess of 500ms with phones on the same network.  With quiet mode on, the issue at least under my light testing seems to be resolved.  I dont have the time to test this on CVS-HEAD, can anyone confirm or deny that this bug has been solved on HEAD?

This is definitally still an issue in stable, at least as of 1.0.7.

By: Tony Mountifield (softins) 2005-05-09 09:49:37

I was the original submitter of this bug, and as far as I am concerned it is still an issue and has not been fixed in HEAD. There have been a couple of (IMHO) wrong attempts to fix it in HEAD in a different way from what I proposed, but I don't have time to fight a battle over it at the moment. I can always just keep it fixed the right way in my own tree, even though it's a pain to have to.

If you're using Stable (e.g. 1.0.7), please try applying my stable-v2 patch listed above, and see if it helps. If it does, please report back here.

Kevin - do you fancy revisiting this one, since you were supportive of it early on?

By: johnnyd (johnnyd) 2005-05-11 02:55:46

For what it's worth: We have switched to V1.0.7 and experienced the same problems as in my posted tests above. The patched CVS version was working, but was not stable enough for production purposes.

We recently changed SIP provider and are not seeing significant delay issues (although still on V1.0.7).

For information, the "3rd party" application "app_conference" handles these issues very well by slowly re-synchronising the frames, and letting the jitter buffer mechanism mask the re-sync. We could not use this application in production as it does not handle the G729 codec without seg faults.

But it has a much more robust way to handle mis-sync between the channels.

By: Tony Mountifield (softins) 2005-05-17 03:26:21

I've discovered that another independent cause of delays is an inaccurate ztdummy driver under kernel 2.6. Please see ASTERISK-4199 for details.

Note that that issue does not supersede this one, as this one also applies when using hardware timing.

By: tripp donnelly (trippd6) 2005-05-30 18:11:26

I have recreated the issue using 2 IAX2 channels in a meetme conference with a software timer. There is a noticable (1-2) second delay on the conference when not using the q option. When using the q option, the delay is gone (or atleast sigifficatnly reduced). After applying the patch, the problem goes away. This is all with HEAD as of 05/19/05.

Just wanted to re-raise the issue. If this patch is not the way to properly fix the issue, I would like to see it get properly fixed and included in CVS.

By: Olle Johansson (oej) 2005-07-18 06:25:52

kpfleming: I think this is waiting for your response.


By: Tom (thgood) 2005-07-20 15:54:11

I have a gradual increase in delay when using meetme.  At first the conference works well but after approx 5 minutes the system has a long delay and is unusable.  I am using ztdummy for timing and have tried 1.0.9, CVS-HEAD and CVS-HEAD patched with V3 posted above.  I have tried it with and without the meetme q option.  The problem is consistent and easily reproducible.  

In my test I had an XLite softphone connected to the meetme bridge.  Then I connected with a Sipura ATA. I would speak into the Sipura and listen for the output through XLite.  After 5 minutes the delay would always be present.  

Note: if I hung up the Sipura leaving the XLite connected to the bridge, then dialed back in on the Sipura the delay would go away for another 5 minutes.

By: Michael Jerris (mikej) 2005-09-02 20:46:52

Ok lets try to keep this one on track.  There were 3 original issues with this.  Bad ztdummy timing source (fixed in cvs head), increasing delay over time on voip channels (that needs to be opened as a different bug, as it is a different issue) and the original issue from this bug report, which is the increased delay caused by entrance and exit tones (and likely the admin menu as well).  Can somone conclusively test and report that there is still an increasing delay caused by the entry\exit tones when using real zap hardware (and NO voip participants) in CVS HEAD?

By: Michael Jerris (mikej) 2005-09-02 20:49:24

Quick correction, the increasing delay over time on voip channels already has an open bug ASTERISK-4152.  Please take all discussion of increasing delay on voip channels to that bug as it is a different issue.

By: Michael Jerris (mikej) 2005-09-09 19:54:40

If no one is willing to comment on this, is it no longer an issue, or is it just that no one cares enough to test?

By: mochouinard (mochouinard) 2005-09-09 22:45:18

my personal experience is by using the new rtc code for kernel 2.6 (currently disabled by default) It fixed all my delays problems. (running CentOS 4.1)

By: Tony Mountifield (softins) 2005-09-10 03:57:47

This particular bug (delays caused by entrance and exit tones and announcements, and possibly the admin menu) is not related to ztdummy. I experienced it using a X101P hardware timing source.

I still maintain that playing to the whole conference channel should be done by a separate thread, as per my patches, and as per anthm's app_confcall. For some unknown reason Mark wasn't keen. Life's too short to make a battle over it - if it doesn't get into CVS, I'll just have to keep patching my own copy to fix the bug, but that would be a pity.

By: Michael Jerris (mikej) 2005-09-10 07:30:14

As I said, we need somone to TEST that this is not an issue on a zap only conference call.

By: Brian West (bkw918) 2005-09-11 12:26:42

softins I would just fix it locally and move on.  Its not worth the time, 7 months to get something resolved is just down right unacceptable.  We have tried to fix this in the past also.  The clear solution is an extra tread for playing sounds to the conference but the powers that be seem to think that is a performace hit.  Look we aren't running on 486's anymore here you can spawn thousands of threads per second without any performace hit... you can do millions of mallocs a second so the argument that its a performace hit is just rubbish.


By: pupfuzz (pupfuzz) 2005-09-21 13:59:23

I'm responding to MikeJ's message (09-02-05 20:46 / 09-10-05 07:30) about needing to test on pure Zap hardware without VOIP, where he asks "Can somone conclusively test and report that there is still an increasing delay caused by the entry\exit tones when using real zap hardware (and NO voip participants) in CVS HEAD?"

NOTE: When I talk about "delay" below, I mean the immediate delay introduced by the entry/exit tones, and not increasing delay over time. The delays I experience occur immediately from the beginning of the conference, even though they appear to only be related to VOIP.

Here is my system setup and results...

2 Zap hardware phones connected via TDM400P
1 VOIP phone (tried grandstream & polycom phones, same results)
Asterisk CVS HEAD 2005-09-17 13:52:06 UTC
Fedora Core 4, Kernel 2.6.12-1.1398_FC4smp #1 SMP

TEST 1:  Meetme(751|dq)
Right after two zap phones have entered conference, there is no delay.
Adding a VOIP phone on top of that, there is still no delay. Best case scenario.

TEST 2:  Meetme(751,d)
Right after two zap phones have entered conference, there is no delay.
Adding a VOIP phone is still pretty good, but there is a small delay added into the VOIP caller's voice (about 150ms?). When Zap callers speak, the VOIP participant hears without delay. When VOIP caller speaks, Zap users hear a slight delay of VOIP caller's voice (still no delay between Zap callers)

TEST 3:  Meetme(751,di)
Right after two zap phones have entered conference, there is no delay. However, adding a VOIP phone to the mix causes a 1.1 second delay in the transmission of VOIP caller's voice to zap participants. There is no delay in transmission of zap callers to VOIP or between zap only. So the delay is assymetric -- the VOIP caller hears the zap hardware callers' voice immediately, but zap callers hear the VOIP caller with a 1.1 second delay.

I don't know what the implications are of the above results, but hopefully this data helps resolve the issue of what needs fixing. I'd really like to use the 'i' option in meetme, but the 1.1 second delay that is introduced by it really gets in the way.

By: Olle Johansson (oej) 2005-10-25 09:43:01

This patch severly needs attention before 1.2.

I'll force it onto kpfleming.

/Housekeeping, first floor

By: Tony Mountifield (softins) 2005-10-25 10:52:11

pupfuzz: very useful test results- thanks! Just one detail missing: were these results obtained with standard CVS-HEAD, or after applying the v3 patch?

If these results are on an unpatched system, could you try applying the patch and see if the results are better? (the patch might need some tweaking or applying by hand as it is now fairly old)

Personally, I have never seen any delay with only zap channels, since it is the instantaneous data in the hardware that is mixed and written out again. It is only when non-zap audio passes to and from a pseudo-channel that we get issues if that passing is delayed.

By: pupfuzz (pupfuzz) 2005-10-27 01:04:00


My results were obtained using CVS HEAD without any patches. I'll try to see if I can find some time to try the v3 patch this weekend when no one is using the system.

By: puzzled (puzzled) 2005-11-04 09:40:39.000-0600

softins: any change you could update your app_meetme-head-v3.diff patch to get it back in sync with cvs HEAD? I manually fiddled around with it but it seems some stuff has changed and I have no clue how to get your patch working again. Thanks!

By: Tony Mountifield (softins) 2005-11-04 10:05:27.000-0600

puzzled: ok, I'll have a go over the weekend.

By: Kevin P. Fleming (kpfleming) 2005-11-08 00:12:03.000-0600

I am starting to work on this issue (finally) so we can have a resolution before 1.2 is released.

It looks like everything is well summarized here and that we have a potential working solution; is there anything else pending or any information to add?

By: Tony Mountifield (softins) 2005-11-08 11:41:55.000-0600

I've just uploaded a v4 patch which is effectively the same as the v3 patch but updated to CVS HEAD as of 2005-11-08.

It compiles fine, but I have not yet tried running it.

By: Kevin P. Fleming (kpfleming) 2005-11-08 18:31:23.000-0600

OK, I'm not discounting the potential benefits of your patch regarding having the new caller hear the 'enter' sound (and maybe others), but Mark and I have come up with a far simpler solution that has solved the problems we've been able to reproduce (this one and ASTERISK-4224252). That solution is now in CVS HEAD.

If you still experience these problems, please reopen the bug and we'll try to get it taken care of, but this should be resolved for good now :-)

By: Digium Subversion (svnbot) 2008-01-15 15:25:28.000-0600

Repository: asterisk
Revision: 5036

U   trunk/apps/app_meetme.c

r5036 | markster | 2008-01-15 15:25:28 -0600 (Tue, 15 Jan 2008) | 2 lines

Begin autoservice while playing enter/leave sounds (bug ASTERISK-3519)



By: Digium Subversion (svnbot) 2008-01-15 15:26:49.000-0600

Repository: asterisk
Revision: 5131

U   trunk/apps/app_meetme.c

r5131 | markster | 2008-01-15 15:26:49 -0600 (Tue, 15 Jan 2008) | 2 lines

Flush MeetMe at appropriate times (bug ASTERISK-3519)



By: Digium Subversion (svnbot) 2008-01-15 15:27:04.000-0600

Repository: asterisk
Revision: 5148

U   trunk/apps/app_meetme.c

r5148 | markster | 2008-01-15 15:27:03 -0600 (Tue, 15 Jan 2008) | 2 lines

Fix meetme flushing stupidity (doh!) (bug ASTERISK-3519)



By: Digium Subversion (svnbot) 2008-01-15 15:55:01.000-0600

Repository: asterisk
Revision: 7033

U   trunk/ChangeLog
U   trunk/apps/app_meetme.c
U   trunk/configs/meetme.conf.sample

r7033 | kpfleming | 2008-01-15 15:55:00 -0600 (Tue, 15 Jan 2008) | 2 lines

issues ASTERISK-3519 and ASTERISK-4152