Are you saying that the audio streams from x seats in a conference are mixed on the card and returned as x unique streams (since each seat needs the mix from everybody except themselves)?
I’m not sure of the fine details, as I’ve never used DAHDI with real cards, but the code is dotted with DAHDI IOCTLs, which involve voice frames, not timing.
There is some information on the conference bridging support at:
if (s->ops->sync_tick)
s->ops->sync_tick(s, dahdi_is_sync_master(s));
}
#else
#define dahdi_sync_tick(x) do { ; } while (0)
#endif
/**
* _process_masterspan - Handle conferencing and timers.
*
* There are three sets of conference sum accumulators. One for the current
* sample chunk (conf_sums), one for the next sample chunk (conf_sums_next), and
* one for the previous sample chunk (conf_sums_prev). The following routine
* (rotate_sums) "rotates" the pointers to these accululator arrays as part
* of the events of sample chink processing as follows:
*
* 1. All (real span) receive chunks are processed (with putbuf). The last one
* to be processed is the master span. The data received is loaded into the
* accumulators for the next chunk (conf_sums_next), to be in alignment with
* current data after rotate_sums() is called (which immediately follows).
* Keep in mind that putbuf is *also* a transmit routine for the pseudo parts
One of the card drivers has a whole file dedicated to conference bridging, so I assume that card had hardware conference bridge support: https://github.com/asterisk/dahdi-linux/blob/master/drivers/dahdi/oct612x/octdeviceapi/oct6100api/oct6100_api/oct6100_conf_bridge.c
system
September 25, 2020, 11:04pm
23
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.