[Freeswitch-dev] Questions about read_frame and write_frame events

Tue Nov 10 07:03:23 PST 2009

Thanks  very much Anthony.

It is quite clear now but I wonder if anyone could suggest me the proper way
to go about this problem

My device has a buffer of 64 bytes equal to 8 ms of PCMA/PCMU so in the
write_frame I need to write 64 bytes of PCMA to the device every 8 ms.
Attempt to more at a time will cause frames lost. 

However, codecs in freeswitch only support ptime of multiple of 10 (10, 20,
30, 40.) so the work around that I go for is to take ptime = 40 ms since 40
can device by 8.

It means, every 40 ms the write_frame event will be called right? And the
frame->data will have 320 bytes so I try to write to the device 5 times,
each time 64 bytes. Still trying different ways for this problem as I
haven't achieved a good timing yet. 

Anybody has added support for ptime of multiple of 2, 4 or 8 for G711 before
?

Regards

Alex To

From: freeswitch-dev-bounces at lists.freeswitch.org
[mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of Anthony
Minessale
Sent: Tuesday, November 10, 2009 2:00 AM
To: freeswitch-dev at lists.freeswitch.org
Subject: Re: [Freeswitch-dev] Questions about read_frame and write_frame
events

yes you must return a frame marked SFF_CNG rather than a NULL frame.

The TFLAG flags are all arbitrary, you can get rid of all of them if you
wish they are just an example of how those modules communicate internally.
Sometimes they were used for the host technology to have a way to mark the
channel so the call should die but you may get the same effect by just
hanging up the channel since the core now does a lot of this and may never
let your read func even be called.

On Mon, Nov 9, 2009 at 3:54 AM, Alex To <tonhudung at gmail.com> wrote:

Thank you very much Mathieu

So if TFLAG_IO is not set, read_frame will return immediately and *frame is
NULL ? Is it a normal behavior if the call is terminated when a NULL frame
is returned ? 

Coz when I return a NULL frame, the call is terminated. So now my
understanding is that if my endpoint buffer is empty, I need to return a
silence frame to the other end, right?

Thank again Mathieu for your quick reply, that helps a lot J.

Regards

Alex To

From: freeswitch-dev-bounces at lists.freeswitch.org
[mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of Mathieu
Rene
Sent: Monday, November 09, 2009 2:54 AM
To: freeswitch-dev at lists.freeswitch.org
Subject: Re: [Freeswitch-dev] Questions about read_frame and write_frame
events

Hi,

See answers inline.

Mathieu Rene

Avant-Garde Solutions Inc

Office: + 1 (514) 664-1044 x100

Cell: +1 (514) 664-1044 x200

mrene at avgs.ca

On 8-Nov-09, at 4:21 AM, Alex To wrote:

Hi,

I am getting stuck on read_frame and write_frame in my custom endpoint.
Would someone shed some lights on how it works?

My questions about read_frame, write_frame after reading mod_iax,
mod_portaudio and mod_skyiax are:

1.       Is it correct that I need to check a flag (for e.g TFLAG_HUP)  of
the private object at the beginning of the event to determine whether I
should continue reading audio or just return. The flag TFLAG_HUP is set when
a hangup or kill channel event is detected.

Thats what TFLAG_IO is for, clear the flag the read_frame functions should
return immediately.

If you catch TFLAG_BREAK, on the other side, you should clear it and return
a comfort noise frame ( cng )

2.       Read_frame is called on an interval (how frequently is the interval
? how do I determine that?) to read audio from my endpoint.

It depends on the codec you are using, if you are using 20 packetization
time, it'll be called every 20ms.

3.       What is TFLAG_IO normally used for ?

See point 1

4.       What is the label "cng" is all about ? May I know what "cng" stands
for and how it is used?

CNG stands for Comfort Noise Generation, whenever read_frame jumps there, it
returns a frame of silence. It it first initialized on private_t since its
pointless to re-allocate empty frames.

5.       What if read_frame is called while my end point is not ready to
send any audio yet?

That's why you set TFLAG_IO whenever you are ready. Also note that it wont
be called until you either pre_answer (go in early media) or answer the
channel.

When a call is made, switch_ivr_originate() doesn't return until your
endpoint is ready to exchange audio.

6.       What is the tech_pvt->cng_frame is used for? I notice that the
*frame is set to tech_pvt->cng_frame if the label "cng" is reached.

See point 4.

Thank you very much for even reading my questions. I tried to look for
documents that explains clearly the above questions but so far no luck.
Until now I still don't have a clear understanding about these 2 events yet.

Best Regards

Alex To

_______________________________________________
FreeSWITCH-dev mailing list
FreeSWITCH-dev at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org

_______________________________________________
FreeSWITCH-dev mailing list
FreeSWITCH-dev at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org

-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale at hotmail.com
<mailto:MSN%3Aanthony_minessale at hotmail.com> 
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
<mailto:PAYPAL%3Aanthony.minessale at gmail.com> 
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
<mailto:sip%3A888 at conference.freeswitch.org> 
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org
<mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org> 
pstn:213-799-1400

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20091110/859e5556/attachment-0001.html 