I am using Meeting on 1.4.43 with a handfull of devices, like 10 to 20 in a Meetme. I can "tell" a difference (as two of the devices are close to each other) that they are not fully in "sync". One was slightly behind the other... Any way to get them more in sync? Is it the delay from starting each device in the MeetMe? time to start device 1 till device X? I was expecting them to be all receiving the data for audio at the same time. Thanks, Jerry
----- Original Message -----> From: "Jerry Geis" <geisj at pagestation.com> > To: "Asterisk Users Mailing List - Non-Commercial Discussion" <asterisk-users at lists.digium.com> > Sent: Monday, October 1, 2012 5:01:43 PM > Subject: [asterisk-users] MeetMe > > I am using Meeting on 1.4.43 with a handfull of devices, like 10 to > 20 > in a Meetme. > > I can "tell" a difference (as two of the devices are close to each > other) that they are > not fully in "sync". One was slightly behind the other... Any way to > get > them more in sync? > Is it the delay from starting each device in the MeetMe? time to > start > device 1 till device X? > I was expecting them to be all receiving the data for audio at the > same > time.Nothing happens "at the same time", unless you're broadcasting information over some transport that supports multicast sends. There's always going to be some interspersing of transmissions, if for no other reason than each participant's channel in the conference has to be serviced after the media has been mixed. With a sufficient number of participants, there will be some 'delay' between when the audio is sent to participant #1 to participant #n. Even if we assume that the transmissions are being done completely "in parallel" using multiple threads, you can still overcome the capabilities of a system by having a sufficiently large number of participants in a conference. That is, for any given system, you can always add more participants, such that, eventually, a thread will not be serviced immediately when it has data to send to a participant. A context switch will have to occur, resulting in the data being sent to said participant at a latter time, resulting in the work being done not "at the same time". Note that recent versions of Asterisk (10+) have a revamped conferencing application (ConfBridge) that, in performance tests, performed much better than MeetMe. A big limitation of MeetMe is its reliance on DAHDI for mixing. ConfBridge removed this limitation, and typically can mix more participants at a faster rate. -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org
On Mon, 1 Oct 2012, Jerry Geis wrote:> I am using Meeting on 1.4.43 with a handfull of devices, like 10 to 20 > in a Meetme. > > I can "tell" a difference (as two of the devices are close to each > other) that they are not fully in "sync".You would have to measure how many ms they are 'out of sync' to determine if there is an issue or not. If you want a real eye-opener, try talking and listening to yourself with a cell phone on each ear. The delay can be several hundred ms and yet nobody ever complains because in the 'real world' we never listen to 2 endpoints at the same time. For future reference... A better subject may yield better answers. -- Thanks in advance, ------------------------------------------------------------------------- Steve Edwards sedwards at sedwards.com Voice: +1-760-468-3867 PST Newline Fax: +1-760-731-3000
> Nothing happens "at the same time", unless you're broadcasting information > over some transport that supports multicast sends. There's always going to > be some interspersing of transmissions, if for no other reason than each > participant's channel in the conference has to be serviced after the media > has been mixed. With a sufficient number of participants, there will be > some 'delay' between when the audio is sent to participant #1 to > participant #n. > > Even if we assume that the transmissions are being done completely > "in parallel" using multiple threads, you can still overcome the capabilities > of a system by having a sufficiently large number of participants in a > conference. That is, for any given system, you can always add more > participants, such that, eventually, a thread will not be serviced immediately > when it has data to send to a participant. A context switch will have to occur, > resulting in the data being sent to said participant at a latter time, > resulting in the work being done not "at the same time". > > Note that recent versions of Asterisk (10+) have a revamped conferencing > application (ConfBridge) that, in performance tests, performed much better > than MeetMe. A big limitation of MeetMe is its reliance on DAHDI for > mixing. ConfBridge removed this limitation, and typically can mix more > participants at a faster rate.Mathew, Makes sense does it help that the system should not be "mixing" as I have set it up (I think) that it is PA only, there is no talk back. I am using options l and q in meetme. Should be listen only. Thanks Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20121001/6458c2e3/attachment.htm>