Hi Moises, On Wed, Jul 27, 2011 at 1:21 PM, Juraj Fabo <juraj.fabo@gmail.com> wrote:
According to return value of sangoma_get_rx_queue_sz() the default rx queue size is 10.
That is correct. And you can change that in the FreeTDM wanpipe.conf configuration to set a different default or by using FTDM_COMMAND_SET_RX/TX_QUEUE_SIZE
My target platform is SLES 11. I installed wanpipe-3.5.20 but did not find the queue setting within wanpipe.conf (at least not explicitely as queue size) However, setting it via libfreetdm API was successful.
Actually, why the ftdm_channel_read() does not read them ALL at once and sets the number of read bytes via *datalen output parameter? (assuming provided *data buffer is large enough) In my tests, always 160 bytes were returned in one particular read.
Did you verify this by providing bigger buffer and datalen?
The reason is that you typically want to handle voice as soon as is available, otherwise you add delay in your audio path, therefore you never leave your voice to accumulate in the driver's buffer's. FreeSWITCH and all other users of the FreeTDM API work this way.
Yes, I just have different framing on the second network stack = 20ms, while on the E1 I have 10ms, that was why I asked about the reading method. Since read is done by polling, I would like to initiate it from the other network stack thread (here I use ACE framework and have all streams/mixers triggered from single Reactor/thread) My problem is that I'm experiencing unexpected latency in the test environment. I have two server, first with sangoma a104d and second with 2xa102de cards connected with E1 cables. First server is serving as a 'loopback', configured in telko mode and all it does is that in loop it reads all active channels and immediatelly writes read data to the same channel. My measurements show latency about 180ms from the write on the second server till read of the same speach on the second serve r in case of single call. I tried to reduce the queue size as described above, however it seems that some frames got lost then. My intention was to use single thread to handle read/write operations on all active channels, which is different than the approach described in freetdm/doc/locking.txt (where thread per call leg is mentioned). I worry most about calling the wait_channel() with timeout = -1 which afaik leads to blocking wait on single channel. As mentioned earlier, when this is called from single thread prio each particular ftdm_channel_write() it represents danger of blocking and latency. I measure time spent in each particular channel wait+write and the result was < 10us. Maybe rather a simple question, does the application which uses libfreetdm need to run thread per call/channel?
In the future you might want consider asking this questions in the freeswitch-dev mailing list to have better chances of a prompt response (as long as the question involves C development with FreeSWITCH/FreeTDM internal APIs).
should I repost also this? Thanks Juraj -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/freetdm-api-ftdm-channel-read-... Sent from the freeswitch-users mailing list archive at Nabble.com.