next »

[jballi]

BASS v2.4.8.1
Windows XP SP3
Average internet connection (~3 Mbps)

I was able to duplicate this anomaly on the XMPlay and Trout players.

When connecting to a low-bandwidth server (I only have one example: http://72.13.83.87:9012), BASS cannot keep up.  Well, not on my PC anyway.  The stream is stalling every 20 to 40 seconds or so to refill the buffer.  In my independent tests, it takes more than 6 seconds to fill up a 5 second buffer which means that no matter how large the buffer is made, playback will eventually stall.

The weird thing is that if I play this exact same URL on Winamp, the stream never stalls.  Winamp has no problem handling the stream with a ~64K buffer while BASS struggles with a much larger buffer (default of ~156K for this stream).

Any ideas, suggestions, recommendations, etc. Thanks in advance for your assistance.

[Ian @ un4seen]

That stream's bitrate is actually quite high at 256kb/s (I would consider low bandwidth to be more like 64kb/s). That's still well under your 3mb/s connection speed, but perhaps there is some congestion between the server and you that means the required transfer rate can't be sustained. That seems to be the case for me (here in the UK), as it is stalling in Winamp too when I try to play it. Are you sure the same URL never stalls in Winamp there? Perhaps you were actually playing a low bandwidth stream in Winamp rather than the one above?

[jballi]

That stream's bitrate is actually quite high at 256kb/s (I would consider low bandwidth to be more like 64kb/s). That's still well under your 3mb/s connection speed, but perhaps there is some congestion between the server and you that means the required transfer rate can't be sustained. That seems to be the case for me (here in the UK), as it is stalling in Winamp too when I try to play it. Are you sure the same URL never stalls in Winamp there? Perhaps you were actually playing a low bandwidth stream in Winamp rather than the one above?

Thank you for taking the time to respond.

I'm sorry for the confusion. What I meant by low-bandwidth is not the stream itself but the server's capacity. The stream's high 256kb/s bitrate just makes it easier to expose the problem.

Yes, there are are many conditions that can cause this problem - 1) limited client bandwidth, 2) network congestion/problems and 3) limited server bandwidth.  Yes, I too can get Winamp to stall if I overload the connection and then try to play the stream.

But and however, when all conditions are ideal (or satisfactory at least), BASS consistently stalls and Winamp never stalls.  I don't really mean never.  My tests last for 5 to 10 minutes.  I really wish you (or anyone) could duplicate the problem I'm having.  And no, I double checked.  Winamp is connecting to the exact same server and port that BASS is connecting to.

From a non-technical perspective, Winamp appears to be able to download faster from this server than BASS, at least with the current configuration.  To test this theory, I modified Winamp so that it has the same buffer size as BASS for this 256kb/s stream.  Like I mentioned in the 1st post, BASS takes more than 6 seconds to load it's entire default 5 second buffer.  Winamp is able to load the same size buffer in ~3 seconds.  At this load rate, the BASS player will always stall regardless of the buffer size and Winamp will never stall.

If you are able to duplicate my results and/or if you have any ideas on how to improve BASS's performance for this server, please post it!  Thank you for your feedback and assistance.

[Ian @ un4seen]

From a non-technical perspective, Winamp appears to be able to download faster from this server than BASS, at least with the current configuration.  To test this theory, I modified Winamp so that it has the same buffer size as BASS for this 256kb/s stream.  Like I mentioned in the 1st post, BASS takes more than 6 seconds to load it's entire default 5 second buffer.  Winamp is able to load the same size buffer in ~3 seconds.

Please also confirm the prebuffering settings that you are using with BASS and the Winamp MPEG plugin. The Winamp plugin's default appears to be to prebuffer 40%, while BASS_CONFIG_NET_PREBUF defaults to 75%, which could explain the different times taken to prebuffer. Also, following a buffer underrun, the Winamp plugin appears to prebuffer only 10% by default, while BASS currently always prebuffers 50% in that scenario. To see whether that is having a bearing, you could try setting the Winamp plugin to prebuffer 50% following buffer underruns too.

[jballi]

Please also confirm the prebuffering settings that you are using with BASS and the Winamp MPEG plugin. The Winamp plugin's default appears to be to prebuffer 40%, while BASS_CONFIG_NET_PREBUF defaults to 75%, which could explain the different times taken to prebuffer. Also, following a buffer underrun, the Winamp plugin appears to prebuffer only 10% by default, while BASS currently always prebuffers 50% in that scenario. To see whether that is having a bearing, you could try setting the Winamp plugin to prebuffer 50% following buffer underruns too.

I was very careful to do an "apples to apples" comparison.  For BASS, pre-buffering (BASS_CONFIG_NET_PREBUF) is turned off.  Playback is not started until the entire buffer (BASS_CONFIG_NET_BUFFER) is full.  The default buffer for this stream is 160,000 bytes (~156K).  For Winamp, I set the buffer size to 157K.  The "streaming prebuffer" is set to 100% so that playback does not begin until the entire buffer is full.  The "prebuffer after a buffer underrun" is set to 60% but it is never triggered since the stream doesn't stall.

Thank you for your interest and your feedback.

[Ian @ un4seen]

If you inspect the network traffic (eg. using Ethereal), do you see anything different between when you use BASS and Winamp to play the stream? Also, does the problem only affect this particular stream/server, or is it happening with others too?

[jballi]

If you inspect the network traffic (eg. using Ethereal), do you see anything different between when you use BASS and Winamp to play the stream?

I quit using Ethereal a while back because it kept crashing my computer.  I don't really have any networking monitoring tools except SmartSniff.  It's is a poor replacement for Ethereal but it's what I got.

After closing all programs that use the internet, I ran the BASS player for 60 seconds, Winamp for 60 seconds, and to add another BASS perspective, I also ran the latest version of XMPlay for 60 seconds.  These are the statistics:

BASS: 1,447 packets; 1,696,421 bytes
XMPlay: 1,336 packets; 1,567,797 bytes
Winamp: 1,847 packets; 2,163,550 bytes

As expected, BASS and XMPlay stalled several times during this test and Winamp never stalled.  Since the buffer sizes are the same, the Winamp statistic represents the approximate amount of data that is needed for this 1 minute test.

Also, does the problem only affect this particular stream/server, or is it happening with others too?

Although I'm sure that I can find other problematic servers (Hint: Look for low capacity servers with high quality (256+ kbps) streams, so far this is only one that I've run into that has this particular problem.  All of the other streams that I've used work fine with BASS.

Once again, thank you for interest and your feedback.  If you (or anyone!) can duplicate my results or if you have any ideas on how to resolve this problem, please post it!

[bkapusta]

I see the same thing and my Icecast server and my Bass application are on node (same server). Ive been spending a lot of time tweeking buffers etc but the stream still stalls every 5-10 min and winamp never stalls.  My stream is only a 16k MP3. 

[bkapusta]

Odd thing is if I set BASS_CONFIG_NET_BUFFER real high, say 10000 (10s) and BASS_CONFIG_NET_PREBUF to 50 the stream starts and the buffer stays between 40 - 60%, I would expect it to start at 50% and climb to 100% but it never does.

[bkapusta]

If I dump the buffer to the screen I see it going from 100 down to ~40% and then back to 100 over a period of time and some times it hits 0.  Is there a setting to tell the stream how quickly to pull the data from icecast?  I think I have tried just about everything.

       Bass.BASS_SetConfig(BASSConfig.BASS_CONFIG_UPDATEPERIOD, 25) '20 ms
        Bass.BASS_SetConfig(BASSConfig.BASS_CONFIG_NET_PREBUF, 50) '50
        Bass.BASS_SetConfig(BASSConfig.BASS_CONFIG_NET_BUFFER, 500) '500ms 
        Bass.BASS_SetConfig(BASSConfig.BASS_CONFIG_BUFFER, 100) '100ms     

[jballi]

Is there a setting to tell the stream how quickly to pull the data from [an internet server]?

I haven't found anything but I'm still a BASS newbie and haven't gone through every option yet.  Are there any BASS experts that can help us with this one?

[Ian @ un4seen]

After closing all programs that use the internet, I ran the BASS player for 60 seconds, Winamp for 60 seconds, and to add another BASS perspective, I also ran the latest version of XMPlay for 60 seconds.  These are the statistics:

BASS: 1,447 packets; 1,696,421 bytes
XMPlay: 1,336 packets; 1,567,797 bytes
Winamp: 1,847 packets; 2,163,550 bytes

Here's a little modification to try...

   www.un4seen.com/stuff/bass.dll

Please let me know what difference (if any) it makes to the numbers and the stalling.

Odd thing is if I set BASS_CONFIG_NET_BUFFER real high, say 10000 (10s) and BASS_CONFIG_NET_PREBUF to 50 the stream starts and the buffer stays between 40 - 60%, I would expect it to start at 50% and climb to 100% but it never does.

A streaming server (eg. Shoutcast or Icecast) will generally keep a certain amount of data buffered, which it can send to new clients, allowing them to prebuffer and begin playback more quickly. Once that buffer has been exhausted and playback has begun, data will be sent by the server at the same rate as it is played by the client, so it's quite normal/expected for the client's amount of buffered data to not increase any further at that point.

[jballi]

Here's a little modification to try...

   www.un4seen.com/stuff/bass.dll

Please let me know what difference (if any) it makes to the numbers and the stalling.

I tried the new DLL.  The results are virtually identical (within 20 packets).

I've done some additional testing and I think I may have some clues that might be helpful.  These clues are mostly based on observation and crude testing.  I'm not a network guy and the tools I do have are limited.

1. The first clue I've mentioned several times - download rate.  It takes more than 6 seconds for BASS to fill up the default 5 second buffer from this server.  Winamp needs just over 3 seconds to fill the same sized buffer.

My player has a progress meter that shows the buffer size while starting and when stalled.  I changed it to always show while playing an internet stream and as a result, I've discovered a few more clues.

2. As expected, the progress meter shows that the consumption rate is faster than the replenish rate.  The buffer will be a certain size (Ex: 80%), fall to 60%, jump back to up to 75%, fall down another 20% segment to 55%, jump back up another 15% segment to 70%, and so on until it flutters between 0% and 5% for a few seconds before it stalls.  While stalled, the buffer fills up to ~50% before playback resumes where the consumption/replenish cycle repeats until it stalls again.

3.  Out of curiosity, I hit Pause to watch the buffer fill up.  As soon as it filled to 100%, I resumed play to see what happens.  As expected, the buffer eventually emptied and playback stalled. See clue #2.  I tried this a few times and I noticed that if I wait a short period of time after the buffer is filled before resuming play, something totally unexpected occurs: the buffer stays full.  The meter shows the buffer jumping back and forth between 80% and 100%.  Sometimes the effect doesn't last and playback eventually stalls but most times playback never stalls.  While playing in this "buffer stays at 100%" mode, SmartSniff reports a higher 60 second data transfer size: 1,678 packets; 1,966,320 bytes.  I haven't figured out the optimal "delay before starting/resuming play" time but it's around 1 second.  BTW, I get same results with BASS v4.2.8.1.

Well, there you go. I hope this helps.  If you would like a copy of my BASS player (it's just a compiled script, prototype version) so that you can see what I'm seeing, tell me where to send/load it and I'll make sure you get a copy.

Thank you for your assistance.

[Ian @ un4seen]

To take this further, I think I will have to send you a debug version to get some information on what is happening with the stream there. So that is what I will do.

[bkapusta]

No difference for me either. 

[jballi]

To take this further, I think I will have to send you a debug version to get some information on what is happening with the stream there. So that is what I will do.

Sounds like a plan.  When you are ready, just let know what you want to do.  If you want to take this offline, feel free to PM me.

Thank you for your assistance.

[Ian @ un4seen]

The debug version was sent yesterday, so you should already have it. If you don't see it, please check your spam folder in case it has ended up in there (quite common for Yahoo).

bkapusta, I have now sent the debug version to you too.

[jballi]

The debug version was sent yesterday, so you should already have it. If you don't see it, please check your spam folder in case it has ended up in there (quite common for Yahoo).

bkapusta, I have now sent the debug version to you too.

You were right.  This message was in the Yahoo Spam folder.  Please note that I've updated my profile with a new email address so hopefully, this problem won't happen in the future.

I performed the requested test per your instructions and I've sent you the resulting log file.

Thank you for your assistance.  Please let me know if you need any additional information.