From e025a651fbab99ccd090f870c944481e45935ff3 Mon Sep 17 00:00:00 2001 From: Shaun Ruffell Date: Fri, 23 Sep 2011 20:18:36 +0000 Subject: [PATCH] dahdi: Check for master in DAHDI_STARTUP / resolves MeetMe regression. There were a couple of reports that MeetMe conferences were not working in 2.5.0.1 and that downgrading to 2.4.1.2 resolved the issue. This could occur if there were no analog spans in a system, and all the digital spans were out of alarm before DAHDI_STARTUP ioctl was called by dahdi_cfg. If the spans were *not* out of alarm, they would be marked master when the span changes it's alarm state. This would result in a condition where no spans were marked as the "master" and so the core timer was handling conferencing. The core timer runs by default at 4ms and most board drivers run at 1ms intervals, but a channel currently only buffers up 2ms of data when conferenced. Therefore, 2ms of audio from a board was continuously dropped from the conference every 4ms by default. This fixes a regression first introduced in 2.5.0 which was specifically added in revision r9611 "dahdi: Do not locate new master in interrupt context." Internal-reference-ID: DAHDI-894 Signed-off-by: Shaun Ruffell Tested-by: Dennis Martinez git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10205 a0bf4364-ded3-4de4-8d8a-66a801d63aff --- drivers/dahdi/dahdi-base.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/dahdi/dahdi-base.c b/drivers/dahdi/dahdi-base.c index 77432fc..f01074e 100644 --- a/drivers/dahdi/dahdi-base.c +++ b/drivers/dahdi/dahdi-base.c @@ -4797,6 +4797,10 @@ static int dahdi_ioctl_startup(struct file *file, unsigned long data) */ s->chans[x]->rxhooksig = DAHDI_RXSIG_INITIAL; } + + /* Now that this span is running, it might be selected as the + * master span */ + __dahdi_find_master_span(); } put_span(s); return 0;