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!

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.

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!

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

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.

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.

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.

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.