[asterisk-dev] nVidia Cuda

Russell Bryant russell at digium.com
Sun Mar 4 10:12:00 MST 2007


Wai Wu wrote:
> 1) Is each channel use their own thread if a codec is used?

Each *inbound* channel uses it's own thread.  The inbound channel then executes 
dialplan applications, which may then create an outbound channel.  In that case, 
you then have these two channels in the same thread.  This has nothing to do 
with what codecs are in use.

> 2) Which part of the asterisk code actually makes the call to the 
> necessary codec? I notice in the applications. They save and set the 
> frame format, then read from the channel. So I trace the read function, 
> but all it does is reading from a file descriptor. So I need some help here.

Codec translation happens can happen in various places, really.  It is anywhere 
ast_translate() is called.  In the most general case, the translation occurs in 
ast_read() and ast_write().  Channels have a read-side translation path and a 
write-side translation path.

For example, you may have two channels with one using ulaw and one g729.  This 
is how the frames would be translated when the channels are bridged together. 
You can see that there is a translation path that must be followed when reading 
a frame from the channel and passing it to the bridge (this happens in 
ast_read), as well as when receiving a frame from the bridge and writing it back 
to the channel (ast_write).

Channel 1                                Channel 2

g729 ----> slinear ||--------|| slinear ----> ulaw
                    || Bridge ||
g729 <---- slinear ||--------|| slinear <---- ulaw


When the channel is executing an application, the situation is similar.  Perhaps 
in your application, you explicitly set the read and write formats to slinear. 
In that case, the translation looks the same.  It still happens in ast_read and 
ast_write.

Channel 1

g729 ----> slinear ||----------------||
                    || My Application ||
g729 <---- slinear ||----------------||

--
Russell Bryant
Software Engineer
Digium, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: russell.vcf
Type: text/x-vcard
Size: 266 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20070304/e8575e7e/russell-0001.vcf


More information about the asterisk-dev mailing list