RadioReference on Facebook   RadioReference on Twitter   RadioReference Blog
 

Go Back   The RadioReference.com Forums > Site Administration Forums > Live Audio Feed Administration

Live Audio Feed Administration Administration topics for live audio broadcasting on Broadcastify.com. This forum is for feed providers to get support.

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old 07-17-2012, 3:17 AM
jaded's Avatar
Member
  Audio Feed Provider
Audio Feed Provider
 
Join Date: Jun 2004
Location: Columbus, OH
Posts: 43
Default Possible to reduce latency?

I provide a live audio feed of a local skywarn repeater, hoping to get weather spotters' severe weather reports, as quickly as possible, to folks who don't have a scanner.

I don't see anything to tweak on my side (running ezstream on linux), but is there anything which can be done on the server side (i.e. radioreference's side) to lower the latency? Unfortunately, the live stream has a delay of at least 45s, and usually more like 70s, depending on the client. Low latency might not be critical for a police dispatcher feed, but getting spotters' reports out with minimal delay, especially when dealing with tornadoes or other severe weather, has obvious benefits.

PS - Thanks to the RR team for making these feeds possible! I still can't believe the scale of what you're doing here -- nice work!
Reply With Quote
Sponsored links
        
  #2 (permalink)  
Old 07-17-2012, 7:17 AM
Member
   
Join Date: Dec 2002
Location: Northern VA
Posts: 195
Default

There are several buffer points that audio feed latency can be caused by...

1. Encoding end... not usually adjustable, as the program and/or codec will determine this buffer. This is to ensure that there is always data to be sent out, in the event of another process using extra CPU time. Probably only adds a couple of seconds of delay... I'd be surprised if it was more than 5 seconds.

2. Server end... may be adjustable by server operators, but would likely affect all feeds. The server buffers a small amount, so that in the event of a momentary interruption of incoming data, there's time for the sending host to recover before the buffer runs out and listeners end up either disconnected or hearing silence. Again, I don't think this buffer causes any significant delays... as the size of this buffer could greatly increase a server's memory requirements, I'd be surprised if it was more than a few seconds as well.

3. Listener end... Almost always adjustable by the user, depending on the player software used... usually made larger if you have a slower or more unreliable connection. Same purpose as the server's buffer, but this one holds the data before playback, in the event of an interruption or delay in communication with the server. Sometimes this buffer is measured in time, sometimes in data size (i.e. buffer x seconds before playback, or buffer x kbytes before playback). If this setting is not adjustable in the player, then it is likely on the large side to accommodate users with slower connections.

#3 will depend largely on the player software and your internet connection. If you have a real slow connection, you may want a larger buffer. Some players take steps to determine your internet connection speed, and will then adjust the buffer size accordingly. Regardless, this is likely to be different from user to user, and is most likely going to be the largest cause of any delay. This can easily add 20+ seconds of delay to a feed.
__________________
Daily Use: GRE PSR-800
NOAA Weather Radio KHB-36 feed: RS Pro-2052
More about my scanner feeds.
Reply With Quote
  #3 (permalink)  
Old 07-17-2012, 11:11 AM
richtidd's Avatar
Live Audio Administrator
  RadioReference Database Admininstrator
Database Admin
Audio Feed Provider
Audio Feed Provider
Amateur Radio Operator
Amateur Radio
 
Join Date: Dec 2002
Location: San Mateo, Ca
Posts: 1,011
Default

Quote:
Originally Posted by jaded View Post
I provide a live audio feed of a local skywarn repeater, hoping to get weather spotters' severe weather reports, as quickly as possible, to folks who don't have a scanner.

I don't see anything to tweak on my side (running ezstream on linux), but is there anything which can be done on the server side (i.e. radioreference's side) to lower the latency? Unfortunately, the live stream has a delay of at least 45s, and usually more like 70s, depending on the client. Low latency might not be critical for a police dispatcher feed, but getting spotters' reports out with minimal delay, especially when dealing with tornadoes or other severe weather, has obvious benefits.

PS - Thanks to the RR team for making these feeds possible! I still can't believe the scale of what you're doing here -- nice work!
Sorry but not really.

Lag is normal.
What you list is normal.
__________________
--
Richard Tidd
Broadcastify.com
Live Audio Administrator

richtidd@broadcastify.com

My online scanners:
SMCo, Tuolumne Co
Reply With Quote
  #4 (permalink)  
Old 07-19-2012, 3:14 AM
jaded's Avatar
Member
  Audio Feed Provider
Audio Feed Provider
 
Join Date: Jun 2004
Location: Columbus, OH
Posts: 43
Default

Quote:
Originally Posted by mikev View Post
2. Server end... may be adjustable by server operators ... I'd be surprised if it was more than a few seconds as well.
Some quick skimming brings up the Icecast config file documentation. I see some interesting parameters: burst-on-connect and burst-size. Specially, it says that burst-size default value is 64KB. With a 128kbps stream, it's a delay of only 4 seconds. But at RR's default of 16kbps, that's 32 seconds right there.

Quote:
3. Listener end... Almost always adjustable by the user
I adjusted the buffer in both Winamp and Foobar2000 (neither would go below 16KB), but it was no help. I suspect that if RR is using Icecast's default 64KB burst buffer, that's what's causing the most significant delay.

Quote:
Originally Posted by richtidd View Post
Lag is normal. What you list is normal.
I'm hoping to see it improve. VoIP phones have sub-200ms latency. Audio-wise, there's not much difference between that and what RR is streaming. There's another discussion to be had concerning network protocols, TCP vs UDP, etc., but I hope you understand where I'm going with this. Icecast might not be designed for low latency applications, but perhaps the weight of being one of the largest implementations of Icecast might encourage development of a better system.

Meanwhile, we have to work with what we've got. I'm going to setup Icecast on a remote server and try to play with it a little. I'll report back if I find anything significant.
Reply With Quote
  #5 (permalink)  
Old 07-19-2012, 7:44 AM
Member
   
Join Date: Dec 2002
Location: Northern VA
Posts: 195
Default

Quote:
Originally Posted by jaded View Post
Some quick skimming brings up the Icecast config file documentation. I see some interesting parameters: burst-on-connect and burst-size. Specially, it says that burst-size default value is 64KB. With a 128kbps stream, it's a delay of only 4 seconds. But at RR's default of 16kbps, that's 32 seconds right there.
Yeah, I suppose at lower bitrates, the time delay can be much larger... my past experiences with Icecast/Shoutcast have been with higher bitrate streams, so I wasn't even thinking about that, hence why I said the server delay was likely only a few seconds.
__________________
Daily Use: GRE PSR-800
NOAA Weather Radio KHB-36 feed: RS Pro-2052
More about my scanner feeds.
Reply With Quote
Sponsored links
        
  #6 (permalink)  
Old 07-19-2012, 9:52 AM
Bellingham_Scanner's Avatar
Member
  Shack Photos
Shack photos
Audio Feed Provider
Audio Feed Provider
Amateur Radio Operator
Amateur Radio
 
Join Date: Mar 2010
Location: Bellingham Washington
Posts: 206
Default

Quote:
Originally Posted by jaded View Post
Some quick skimming brings up the Icecast config file documentation. I see some interesting parameters: burst-on-connect and burst-size. Specially, it says that burst-size default value is 64KB. With a 128kbps stream, it's a delay of only 4 seconds. But at RR's default of 16kbps, that's 32 seconds right there.
I am currently running Icecast along side of the stream I feed to RR.

I have not compared the delay, but feel free to follow the link in my feed provider page and give it a listen.

I think I have the burst on connect disabled, but will have to check.
Reply With Quote
  #7 (permalink)  
Old 07-20-2012, 10:39 PM
jasonpeoria911's Avatar
Member
  RadioReference Database Admininstrator
Database Admin
 
Join Date: Apr 2003
Location: Peoria, IL
Posts: 504
Default

All RR Feeds will have a delay of 30 seconds to a minute or so. If you send the audio to Teamspeak or Proscan, the delay is very minimal if any at all. Your users will have a tougher time accessing the feed though.

Jason
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT -5. The time now is 3:24 PM.


Powered by vBulletin® Version 3.8.2
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
All information here is Copyright 2012 by RadioReference.com LLC and Lindsay C. Blanton III.Ad Management by RedTyger
Copyright 2011 by RadioReference.com LLC Privacy Policy  |  Terms and Conditions