2bc2ebd1de
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> Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10205 git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.5@10207 a0bf4364-ded3-4de4-8d8a-66a801d63aff |
||
|---|---|---|
| .. | ||
| dahdi | ||