Hello, I am currently writing a driver for the XHFC ISDN chip from Cologne Chip, which is interfaced over SPI with an ARM processor (i.e it's not the typical PCI card setup). The fact that it's over SPI means that talking to the XHFC chip is quite slower than talking to memory-mapped devices such as PCI devices.
With the default DAHDI_CHUNKSIZE of 8 bytes, we need to have an interrupt every millisecond to push and pull data from/out of the XHFC chip. And it's quite difficult to do all the necessary SPI communication in one millisecond (not really transferring the 8 bytes, but doing all the administrative stuff such as reading the interrupt flags, etc.). Getting interrupts every millisecond is also generating a fairly significant CPU load. Ideally, we would like to be able to get less interrupts, like only every 4 ms, and therefore push and pull 32 bytes of data at each interrupt. This would however require raising the DAHDI_CHUNKSIZE to 32 bytes instead of the default 8 bytes. What are the consequences of such an increase of the chunk size ? Back in 2010, there was a thread at http://lists.digium.com/pipermail/asterisk-ss7/2010-March/003544.html showing that apparently wasn't really simple. And the document at http://www.sangoma.com/assets/docs/misc/2009_10_09_How_to_Reduce_Asterisk_System_Loads.pdf indicates that if you use any other value than 8 bytes for DAHDI_CHUNKSIZE, you cannot use any software echo cancellation. But both of these things are 4-5 years old, so I'm not sure to what extent they apply to the current DAHDI code base. Do you have any insights/experience about the possibility of raising the DAHDI_CHUNKSIZE ? Thanks a lot, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
