0

I'm implementing a shoutcast radio client.

My reference client sends "Initial-Burst" HTTP request header to 960000. I don't know the initial buffer size of my reference client, it's an iOS app, I don't have the source codes. What I know is it starts playing almost instantly, as soon as user selects a channel.

When I raise my initial buffer size above ~100 kbytes, my radio no longer plays instantly, on some streams it waits for the data from server, which lasts a few seconds.

The server says it's running Icecast 2.3.3-kh3 and Linux v1.9.8. Icecast is an open source software, needless to say it has no documentation.

What units has that Initial-Burst header? bytes, bits, ticks, etc?

Are there some recommended values / best practices?

Brad
  • 159,648
  • 54
  • 349
  • 530
Soonts
  • 20,079
  • 9
  • 57
  • 130
  • "Icecast is an open source software, needless to say it has no documentation." Yes, because the license of software is a perfect indication of the availability of documentation. Icecast does not have the best documentation on specifics, but that isn't universal among open source software. – Brad Jan 07 '13 at 03:27
  • @brad, IMO there's strong correlation. Commercial software needs to be sold. Having a documentation helps, having good documentation helps even more. – Soonts Jan 07 '13 at 08:36

1 Answers1

1

What I suspect is happening is that you are requesting more data than the server has buffered. If you were to request 1MB but your only has 512KB in its buffer, you would then be receiving data as it came from the encoder until your 1MB client-side buffer fills. You can confirm this with a packet sniffer, such as Wireshark.

If you build your own client, you should be able to separate the playback buffer size from the header. Once this is done, you can set your Initial-Burst header as big as you want.

The other possibility (unlikely, I suspect) is that the server is making a server-side buffer and filling it to the requested size before sending. That wouldn't make much sense to me, but again, you can confirm the behavior with a packet sniffer.

What I do is have a fixed buffer size server-side, and ignore any headers related to buffer control. This allows me to flush a large buffer as quickly as possible, without relying on client behavior. I do this with custom code though... I don't think this is configurable in Icecast, but I could be wrong.

Brad
  • 159,648
  • 54
  • 349
  • 530
  • @Soonts, The header value would be in bytes. The reason it exists is so the client could set it at `0`. You would want to do this for a relay stream so that both servers are more in sync. (Each server has its own buffer, so there is no need to double that buffer. Does that make sense?) – Brad Jan 07 '13 at 13:57
  • to be honest I didnt understood your answer. I've created my own player, and I have complete control over what's requested from server, what's buffered, and what's fed to the audio decoder. However, I don't know what you mean "separate the playback buffer size from the header". Also, I don't understood why are you telling me to set it to 0, while the official client sends 960000? 9600000 bytes is about 1.5 - 2 minutes of audio, I don't believe the server has that many.. – Soonts Jan 07 '13 at 14:32
  • @Soonts, I don't suggest to set it to `0`. I was saying that the primary reason the parameter exists is so that relay servers can set it to `0` to get an unbuffered stream. I would recommend making your request without specifying the `Initial-Burst` header. Let the server send its full buffer. If you find that the server isn't actually sending its full buffer in this case, try cranking it up to `512000` or so. I wouldn't go much over that. Most decoders can start playback with 2 seconds of audio buffered. Of course for mobile devices, you want the biggest buffer you can get from the server. – Brad Jan 07 '13 at 18:54
  • thanks for your comments.. Q1. There're streams of different bitrates. Should I adjust the value proportional to the bitrate? – Soonts Jan 07 '13 at 19:12
  • Q2. Some of the stream are good, on that streams server provides unlimited data (i.e. regardless on the buffer size I wait before start playback, my buffer fills almost instantly), there also free streams with advertisements (server only sends ~300-400 kbytes fast, then starts sending bytes with the rate of playback), should I send different Initial-Burst values when playing good streams and free streams? – Soonts Jan 07 '13 at 19:12
  • Q3. Any idea why the official client sends that big value, had they some good reason to implement that? – Soonts Jan 07 '13 at 19:13
  • @Soonts, Q1: You can if you would like. Network latency and packet loss stays constant. I will often adjust the buffer size, but not go lower than 256KB. It depends on how much time delay is acceptable. Q2: I would request the same amount, no matter what. But, you can change it depending on your needs. Q3: Mobile networks are terrible and you need a large buffer. 960KB isn't too unreasonable, but probably a bit bigger than you need. – Brad Jan 19 '13 at 19:37