[Freeswitch-users] freetdm api - ftdm_channel_read()

[jfabo]

Hi Moises,

On Wed, Jul 27, 2011 at 1:21 PM, Juraj Fabo <juraj.fabo at 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-tp6627495p6719985.html
Sent from the freeswitch-users mailing list archive at Nabble.com.