Icecast Streaming Media Server

[cmodyssey]

Hi,

I have a strange problem with ezstream to stream an mp3 file to icecast.

When a listener connects to icecast, the listener does not start playing for a long time because it's loading in a huge amount of the stream data before it's happy with the amount it has buffered and then starts playing.

I have ezstream installed on the same PC as icecast. The listener is on the same LAN as icecast.

When I use simplecast instead of ezstream to stream to icecast, the test listener loads a far smaller amount of stream data and starts playing very quickly.

I have tried getting ezstream to re-encode the mp3 as well and it has not helped.

Does anybody have any ideas what the problem is and what I can do about it.

Thanks in advance.

Here is my config file for ezstream:

[karlH]

That would indicate that it sees something other than mp3 initially, and the player waits to see if it eventually finds something that is mp3. maybe an incorrect intro file?

karl.

[cmodyssey]

Hi Karl,

Thanks for your reply.

I'm not sure what would be seen initially, I've put a censored version of my icecast config at the bottom of this posting.

I get the same problem when I point ezstream to either /live_mount or /replay_mount

I simplified my scenario to just pointing ezstream to /live_mount for now, so that I can show myself that the problem exists with a straight forward setup.

Please could you let me know what to look at next.

Thank you.

[cmodyssey]

Hi,

Another symptom of my problem with ezstream and icecast is that the listener skips loading the large amount of data and will play straight away for a few seconds, then starts breaking up, going silent for a sec, then audible again, going through this cycle a few times until going completely quiet after 16 seconds of when the listener originally started listing.

Has anybody got any ideas on what I can do about either of these symptoms I am getting with ezstream and icecast?

Thanks in advance.

[karlH]

sounds like a bandwidth starvation problem.

karl.

[cmodyssey]

Hi Karl,

I've been doing some more testing on this and varied where I have been running ezstream.

Scenario 1) ezstream on computer 1, icecast on computer 2 and listener on computer 3

Scenario 2) ezstream and icecast on computer 2 and listener on computer 3

When I use ezstream in scenario 1) It works great, listener starts to hear audio straight away, very little buffering before the audio is heard, no breakup of audio.

When I use ezstream in scenario 2) I have problems, what's really weird is that the listener will either a) not start playing for a long time because it's loading in a huge amount of the stream data before it's happy with the amount it has buffered and then starts playing or b) start playing straight away for a few seconds, then breaks up and gives up.

I could maybe understand if scenario 2) resulted only in symptom a) as it's almost as if there is too much bandwidth between ezstream and icecast and the listener (ezstream being on same computer as icecast computer and listener being on same LAN as the icecast computer).

Is there anything I can check anywhere on this?

Thanks.

[karlH]

if you are suggesting that the feed from ezstream may be inconsistent then use a a downloader app/utility like curl to measure the bandwidth taken, if it stays below the expected bitrate then starvation will occur, like wise if CPU usage of the machine is max'd out then that also could be affecting the ability of ezstream to send data.

karl.

[cmodyssey]

Hi Karl,

It took me a while to get round to do these tests, I've been working on the live icecast setup.

The buffering problem is on my test setup, as I've got the source, icecast and the listening client all in the same room.

When it comes to the live setup, then icecast is installed on a server on the internet instead.

So back to my buffering problem on test, where end-to-end it's all in the same room.

In scenario 2) where ezstream and icecast are on computer 2 and the listener is on computer 3 I've done some curl testing.

Test 1) Bandwidth between ezstream and icecast, I ran curl on computer 2 and targeted computer 2 as follows:

[karlH]

I can only go by the figures you are posting but I would say that the source client is not regulating the stream in realtime. 19Mbyte/s ??

karl.

[cmodyssey]

Hi Karl,

That makes a lot of sense and it all fits.

As my source is ezstream, do you have any ideas how I can regulate it's output to be real time, instead of outputting far more audio data per second than necessary?

I already have ezstream configured to re-encode the audio.

Thanks.

[karlH]

not really, you'll have to see where the regulation of the stream takes place. It's not something I've looked at. Could be a misconfiguration preventing libshout to regulate the sender or it could some quirk of the mp3 format that isn't being detected properly. As always I'd check the logging as that should be the first place to look for errors or warnings.

karl.

[cmodyssey]

Hi Karl,

I have just got round to repeating my test and produced a clean error.log

This test is scenario 2) where ezstream and icecast are on computer 2 and the listener is on computer 3 and I get the buffering problem.

So far, we have been thinking that the source needs regulating but having looked at the error.log for the total_bytes_read and total_bytes_sent the rate is quite normal.

E.G. in the first minute of the stream, total_bytes_read=957600 and total_bytes_sent=999022

So 957600/60 = 15960 bytes per sec

15960*8 = 127680 bits per sec

127680/1024 = 125 kbits per sec

I've copied the whole error log below.

I'm really confused, because I expected to see the bytes read and bytes sent to be a whole lot higher, to be consistent with the curl testing I did.

Do you have any clues as to why I'm getting this buffering problem with these throughput figures?

Thanks.