FGCOM/dahdi-linux
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

dahdi: Check for master in DAHDI_STARTUP / resolves MeetMe regression.

Browse Source 
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 <sruffell@digium.com>
Tested-by: Dennis Martinez <dmartinez@digium.com>

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10205 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This commit is contained in:
Shaun Ruffell 2011-09-23 20:18:36 +00:00
parent dfab257fef
commit e025a651fb
1 changed files with 4 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
drivers/dahdi/dahdi-base.c
View File

@ -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;