Old 15th July 2013, 20:52   #1
ivo1234
Junior Member
 
Join Date: Jul 2013
Posts: 3
Buffer issue source >> server

Hi all,

I’ve got an issue with the buffer between the Shoutcast server, and the Winamp Shoutcast source (where the stream is created).

Fist, let me explain how the setup runs:

For a community radio station I setup a stream years ago. It runs fine, but because there is no sufficient bandwidth available for many listeners in the studio itself, the stream is only created over there. The Winamp Shoutcast source (dsp plugin) in the studio, sends its data directly to the Shoutcast server over the internet. The Shoutcast server is connected to a fiber network, so no bandwith issues over there…

The buffer configuration of the Shoutcast server to the listeners works fine. When a listener has a temporary lag in his/her network, the buffer catches this perfectly, and no drop outs will be heard in the audio.

Now the issue:

If for some reason the internet connection between the source (studio) and the Shoutcast server fails for only a fraction of a second, this will be heard in the final stream, which the listeners are listen to.

I don’t understand why there is a great working buffer available (also adjustable(!)) at the server to listener site, but no such (adjustable) option for the source to the Shoutcast server itself. Or am I wrong? (hope so)...

Anyone an idea? Thanks in advance!

Note: I’m using the Winamp Shoutcast dsp plugin 2.2.3 for the source, and Shoutcast 2 for the server itself
ivo1234 is offline   Reply With Quote
Old 21st July 2013, 06:54   #2
thinktink
Forum King
 
thinktink's Avatar
 
Join Date: May 2009
Location: On the streets of Kings County, CA.
Posts: 3,007
Send a message via Skype™ to thinktink
The current version of the SHOUTcast DSP is now 2.3.2. Try that version instead. However, if the internet connection is failing to the point that it actually looses data with just a fraction-of-a-second interruption that apparently happens often enough that it's a problem, it probably means you need to contact your ISP to have it checked out.
thinktink is offline   Reply With Quote
Old 22nd July 2013, 19:38   #3
ivo1234
Junior Member
 
Join Date: Jul 2013
Posts: 3
Thanks Thinkthink,

We’re already running Shoutcast DSP 2.3.2. I mistyped…
Contacting our ISP is not an option, as the connection is working fine for every single service on the internet. Ustream.com for example (which uses a lot more upload bandwidth than a single Shoutcast audio stream), is running fine. No drop-outs at all.

Also adjusted QoS-settings in the firewall don’t solve the issue. I tried that more than once…
ivo1234 is offline   Reply With Quote
Old 22nd July 2013, 21:06   #4
DrO
 
Join Date: Sep 2003
Posts: 27,873
there are buffers on the input side as well as the output (as you've noted). but if the connection drops, there's no guarantee that a complete audio frame was received from the source and until the client attempts to play the audio data, that issue won't be known.

having the DNAS check and filter out incomplete audio frames would help with the issue but that's just not something which is present or really feasible to be doing (as you have to decode things inside the DNAS and so act like a client and be subject to what that entails).

plus the Source DSP is still going to keep trying to encode and send the stream even when the connection drops which can also cause some loss in the audio stream and thus the stream glitches.

though you could say that the client should be able to strip out invalid stream data without impacting on the audio but it depends a lot on how much was lost during the connection failure.


though why you see dropouts is a bit strange if other services are fine and all i can suggest is increasing the timeout on (ideally source) connections at the DNAS and see if that helps with things as it seems like the current limit is not enough for your setup. also checking the DNAS logs to see if it's initiating the connection drop or not may help pin-point things (though am having to guess as no idea what version of the DNAS you're using).
DrO is offline   Reply With Quote
Old 29th July 2013, 20:44   #5
ivo1234
Junior Member
 
Join Date: Jul 2013
Posts: 3
Sorry for my late response, but many thanks for your explanation and enumeration DrO,

Most important in my opinion: ‘’plus the Source DSP is still going to keep trying to encode and send the stream even when the connection drops which can also cause some loss in the audio stream and thus the stream glitches.’’

And just exactly that is my experience with the plugin. The stream to the client/listener keeps on running without having a problem at all, but glitches – caused by data loss between the Winamp Plugin and the Server - are heard for the listener.

And indeed the problem seems to be that DNAS doesn’t check ‘incomplete audio’, but I wasn’t sure if something like that was present… When I read your post, I think there isn’t much I can do about it… Something like that simply doesn’t exist… that's a pitty…

But again, many thanks!
ivo1234 is offline   Reply With Quote
Old 28th February 2014, 11:08   #6
newbornus
Junior Member
 
Join Date: Feb 2014
Posts: 30
It is behaviour of the new DNAS version. Previously i used an old (and buggy) version (sc
server v2 build 29 for linux), it was just fine. I'm using sam broadcaster as source.
When lag between source and server increases, l hear interrupts on the audio stream. Also, in older version the player starts playing stream immediately, in present versions of server there is an interrupt for 3-5 secs before playback starts. Tested on different devices/OSes/platforms/players. I don't know how to handle this, also i don't want back on previous version of server.
newbornus is offline   Reply With Quote
Old 28th February 2014, 11:15   #7
DrO
 
Join Date: Sep 2003
Posts: 27,873
newbornus: what version of things are you using? as the posts in this thread pre-date the Source DSP v2.3.3 and DNAS v2.2.x updates.

is this just from running the DNAS directly or via a control panel / hosting setup?

have you changed settings in the DNAS's configuration or left it at the defaults the DNAS uses for buffering? (which was changed in v2.2.x to be adaptive to the audio bitrate instead of using a fixed buffer as before - which can be easily returned to be setting buffertype=0 in the DNAS's configuration file and restarting the DNAS).
DrO is offline   Reply With Quote
Old 28th February 2014, 11:30   #8
newbornus
Junior Member
 
Join Date: Feb 2014
Posts: 30
SHOUTcast DNAS/posix(linux x86) v2.2.1.109 (Nov 29 2013)
SAM Broadcaster 4.9.8

Just tried the following settings:

buffertype=1
adaptivebuffersize=15

it helps, the stream playback starts immediately.
Note that you have to restart the server completely, reloading the config via web admin panel does not take effect on the buffering setting.
newbornus is offline   Reply With Quote
Old 28th February 2014, 11:52   #9
DrO
 
Join Date: Sep 2003
Posts: 27,873
i did say that the DNAS needs to be restarted for such changes to take effect (is the last thing in my prior post).

as for what you've set, buffertype=1 is the default setting for the v2.2.x DNAS. though increasing the size (from 5 to 15 as you've done) would make sense if it was struggling under your setup with the default of 5.
DrO is offline   Reply With Quote
Old 28th February 2014, 13:04   #10
newbornus
Junior Member
 
Join Date: Feb 2014
Posts: 30
Yes, increasing from default value to 10-15 solved the problem. Otherway the buffer filling process was annoying for me at playback startup.
newbornus is offline   Reply With Quote
Reply
Go Back   Winamp & Shoutcast Forums > Shoutcast > Shoutcast Technical Support

Tags
bandwidth, buffer, buffer issue, source server

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

Forum Jump