I've setup a conference bridge that has perpetual-sound set to a icecast stream. When the first person connects, there is an ~7s delay before any audio is heard. This is similar to a problem reported by Dan here and concluded with Tony adding the channel var "enable_file_write_buffering". The list discussion ended here: http://lists.freeswitch.org/pipermail/freeswitch-users/2009-February/011104.... I set this var in my dialplan: <action application="set" "enable_file_write_buffering=false"/> prior to joining the conference. The first person in still sees a 7s delay on audio the first time in. Like dan, I have icecast setup with burst_on_connect set to 1 but my burst_size is the default 64k so quite a bit of data. Has anyone been able to get an on-demand shoutcast stream from an icecast server to start immediately (or at least within a second)? Thanks. -- -Rupa
Its the buffering and startup of the shout stream taking up the time, HINT put the shoutcast stream into a local stream with a .loc file and then play that in the conference. 2009/4/1 Rupa Schomaker <rupa@rupa.com>
I've setup a conference bridge that has perpetual-sound set to a icecast stream. When the first person connects, there is an ~7s delay before any audio is heard. This is similar to a problem reported by Dan here and concluded with Tony adding the channel var "enable_file_write_buffering". The list discussion ended here: http://lists.freeswitch.org/pipermail/freeswitch-users/2009-February/011104....
I set this var in my dialplan: <action application="set" "enable_file_write_buffering=false"/>
prior to joining the conference.
The first person in still sees a 7s delay on audio the first time in.
Like dan, I have icecast setup with burst_on_connect set to 1 but my burst_size is the default 64k so quite a bit of data.
Has anyone been able to get an on-demand shoutcast stream from an icecast server to start immediately (or at least within a second)?
Thanks.
-- -Rupa
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
2009/4/2 Anthony Minessale <anthony.minessale@gmail.com>
Its the buffering and startup of the shout stream taking up the time,
HINT put the shoutcast stream into a local stream with a .loc file and then play that in the conference.
Ah, that is easy enough! Though I think with icecast doing the burst_on_connect thingie there should be enough data (pushed much faster than real time) to fill FS's buffers. But that would require mod_shout to cooperate with that strategy. ie: on connect, drain the socket as fast as it can filling it's own buffers. Once it's own buffers are full start streaming. I think right now it drains the socket only as fast as it needs to. Or maybe not. <shrug/> I'll go the local stream route for now.... -- -Rupa
participants (2)
-
Anthony Minessale
-
Rupa Schomaker