VoIP Mailing List Archives

[freeswitch-users at di...]

Hi,

With the 1.0.2 release i was able to to stream a call using mod_shout to an icecast server with only a 1 or two second delay to clients. With the current trunk that delay is now 8 to 10 seconds. I thought it might have been a change to mod_shout.c. I tried tweaking a few outbound buffer sizes with no luck so I just copied the 1.0.2 version of mod_shout.c over, compiled and reinstalled the module, restarted fs and still the delay is 8 to 10 seconds. I'm a little stumped. I currently have both versions installed (trunk and 1.0.2) for testing. Both are streaming to the same icecast server.

My current svn revision is 11669, the calls are coming in via sip using g.711 ulaw and it looks like lame/mod_shout is streaming it as a 16kbs, 8khz mono mp3 stream. I'm using a flash/flex applet I wrote to consume the icecast stream, although I have used totem to listen to the stream as well.

Any thoughts

[brian at freeswitch.org]

Yes this will be normal due to buffering. Have you tested svn trunk?

/b

On Feb 6, 2009, at 12:59 PM, Dan wrote:

[freeswitch-users at di...]

I have, do you know what would have changed between 1.0.2 and trunk that would cause the buffer to change? Also if its not in mod_shout.c (which I copied from 1.0.2 to trunk for testing with no luck), where else would fs be buffering? One thing I have noticed is that in 1.0.2 as soon as the dial plan hits my record statement I see mod_shout logging that it has connected to the icecast server, in trunk it takes about 5 seconds to see the same log mesage. Below is my current svn info
Path: .
URL: http://svn.freeswitch.org/svn/freeswitch/trunk
Repository Root: http://svn.freeswitch.org/svn
Repository UUID: d0543943-73ff-0310-b7d9-9358b9ac24b2
Revision: 11669
Node Kind: directory
Schedule: normal
Last Changed Author: brian
Last Changed Rev: 11669
Last Changed Date: 2009-02-06 11:29:51 -0700 (Fri, 06 Feb 2009)

----- Original Message -----
From: "Brian West" <brian@freeswitch.org>
To: freeswitch-users@lists.freeswitch.org
Sent: Friday, February 6, 2009 12:11:54 PM GMT -07:00 US/Canada Mountain
Subject: Re: [Freeswitch-users] mod_shout delay in trunk

Yes this will be normal due to buffering. Have you tested svn trunk?

/b

On Feb 6, 2009, at 12:59 PM, Dan wrote:

[brian at freeswitch.org]

Let me clarify.. yes this is normal file buffering was added so we wouldn't thrash your hard drive with tiny bits of data when recording calls so now it buffers and writes larger chunks to disk. This is why you have this delay which is 100% normal.... is realtime a critical thing? It is shout cast so you know it doesn't have to be realtime.. in fact some clients will buffer a little bit anyway and add to it.

/b

On Feb 6, 2009, at 1:43 PM, freeswitch-users@digitaldan.com (freeswitch-users@digitaldan.com) wrote:

[freeswitch-users at di...]

For me it is. For what I'm using it for I can tolerate around a second or two delay. I have the icecast server setup to only buffer 1K for their on-connect burst as well as my flash/flex player to only buffer 1k (yes I might as well not buffer at all, which I may end up doing). In 1.0.2 this worked very well. Is this buffer configurable? If not, where is it being set?

Thanks
Dan-
----- Original Message -----
From: "Brian West" <brian@freeswitch.org>
To: freeswitch-users@lists.freeswitch.org
Sent: Friday, February 6, 2009 12:47:53 PM GMT -07:00 US/Canada Mountain
Subject: Re: [Freeswitch-users] mod_shout delay in trunk

Let me clarify.. yes this is normal file buffering was added so we wouldn't thrash your hard drive with tiny bits of data when recording calls so now it buffers and writes larger chunks to disk. This is why you have this delay which is 100% normal.... is realtime a critical thing? It is shout cast so you know it doesn't have to be realtime.. in fact some clients will buffer a little bit anyway and add to it.

/b

On Feb 6, 2009, at 1:43 PM, freeswitch-users@digitaldan.com (freeswitch-users@digitaldan.com) wrote:

[anthony.minessale at g...]

edit switch_ivr_play_say.c line 423

comment the line out and recompile.
Tell me if it helps you and i will consider making it configurable.


On Fri, Feb 6, 2009 at 2:01 PM, <freeswitch-users@digitaldan.com (freeswitch-users@digitaldan.com)> wrote:

[freeswitch-users at di...]

That worked great!

I wanted to say just how awesome Freeswitch is, I have been doing voip related development with SIP since 2000 and this is by far the most well designed piece of voip software I have used or developed on. I currently have a homegrown sip server built on the NIST sip stack with Sun's JMF libraries for RTP processing. 95% of the code and complexity is handling the SIP and RTP sessions, the other 5% is the final application logic and what is most important to me. By letting freeswitch do whats its good at (call routing, sip and media handling) it allows me to focus on what I'm good at (what should we do with those streams, like record them). I have been bragging about this project to anybody who will listen!

Dan-
----- Original Message -----
From: "Anthony Minessale" <anthony.minessale@gmail.com>
To: freeswitch-users@lists.freeswitch.org
Sent: Friday, February 6, 2009 1:07:44 PM GMT -07:00 US/Canada Mountain
Subject: Re: [Freeswitch-users] mod_shout delay in trunk

edit switch_ivr_play_say.c line 423

comment the line out and recompile.
Tell me if it helps you and i will consider making it configurable.


On Fri, Feb 6, 2009 at 2:01 PM, <freeswitch-users@digitaldan.com (freeswitch-users@digitaldan.com)> wrote:

[anthony.minessale at g...]

Thanks,

We appreciate the positive feedback!

if you revert the change I suggested and update i added a new variable

enable_file_write_buffering=false

set this variable on the channel before you start recording it with the set application or in the dialstring in {}
on outbound calls and it should skip the buffering.

Could you test it for me and confirm it works?

Thank you


On Fri, Feb 6, 2009 at 2:36 PM, <freeswitch-users@digitaldan.com (freeswitch-users@digitaldan.com)> wrote:

[freeswitch-users at di...]

On line 424 I think it needs to be changed from

if (!vval || !switch_true(vval)) {
to
if (!vval || switch_true(vval)) {

Other wise it works, thanks!

----- Original Message -----
From: "Anthony Minessale" <anthony.minessale@gmail.com>
To: freeswitch-users@lists.freeswitch.org
Sent: Friday, February 6, 2009 1:48:31 PM GMT -07:00 US/Canada Mountain
Subject: Re: [Freeswitch-users] mod_shout delay in trunk

Thanks,

We appreciate the positive feedback!

if you revert the change I suggested and update i added a new variable

enable_file_write_buffering=false

set this variable on the channel before you start recording it with the set application or in the dialstring in {}
on outbound calls and it should skip the buffering.

Could you test it for me and confirm it works?

Thank you


On Fri, Feb 6, 2009 at 2:36 PM, <freeswitch-users@digitaldan.com (freeswitch-users@digitaldan.com)> wrote:

[jalsot at gmail.com]

Hello,

could this option be used to lower I/O load - to rather write more bytes
at once rather than one by one - on file recording (record_session)?

Regards,
Tamas

Anthony Minessale írta:

[msc at freeswitch.org]

[freeswitch-users at di...]

Done!
----- Original Message -----
From: "Michael Collins" <msc@freeswitch.org>
To: freeswitch-users@lists.freeswitch.org
Sent: Friday, February 6, 2009 2:36:39 PM GMT -07:00 US/Canada Mountain
Subject: Re: [Freeswitch-users] mod_shout delay in trunk

[msc at freeswitch.org]

[anthony.minessale at g...]

tamas,

the opposite. The default is to not do one by one and setting the var to false makes it more i/o intensive but it would
provide more real time recording when recording to streams.

BTW the reversed logic is fixed in tree

On Fri, Feb 6, 2009 at 3:36 PM, Tamas <jalsot@gmail.com (jalsot@gmail.com)> wrote: