Delay of 90 seconds

[JohnnyK]

I'm trying to figure out how to broadcast almost live with no more than 10-15 second delay. Media Encoder is down to 10 seconds at 15 Kbs audio streams. The best I can get from Shoutcast is about a 90 seconds delay. Is this normal? (I originally miss-posted this in Winamp, sorry)

[NJK]

yes got to do with QOS = quality of service

meaning that it takes this time to update the things that go with your stream like title update etc
if you want to stream almost without delay Shoutcast isn't the solution .
if you don't mind the delay Shoutcast is a great way to broadcast

[JohnnyK]

Other streaming formats also have overhead. I'm testing this on a dedicated 100 Mbs LAN. No other traffic. There's absolutely no way to reduce the delay?

[Jay]

it's not overhead, it's QoS buffer.

The shoutcast server stores up 1MB of audio data and then when a user connects it pushes as much of that as it can as fast as it can at the user, this has the effect of insta-connect (tm) with no waiting to fill up the local player's buffer. The only way to reduce it is to stream at higher bitrates, there is no way to totally eradicate it though.

[aMUSiC]

How accurate is the 1MB buffer size? Supposedly at 64kbps (8kb/sec roughly) the 1024kb buffer fits 128 seconds of streaming data. Taking in account the client's buffer as well as any source buffer, this would more likely grow into a 2:30 minute delay.

However this is not the case as during tests the actual delay might vary from 30 to 60 seconds.

Is there something that I'm missing here?

[Nick@ss]

the average delay in a good connection is between 20 - 90 seconds as the other said the higher the bitrate the lower the delay

[Fermulator]

Yeah......

About that....

I just installed ShoutCast server.

I have only two computers in the house.

As some, I'd like to have both computers play the SAME SONG, SYNCHRONIZED, at the same time.

I've got actually very close.

1. Setup the ShoutCast server on Computer1.
2. Installed the DSP pluggin for Winamp on both Computer1 and Computer2.
3. "Enabled" the DSP plugin on Computer2.
a. Configured the "Options" for the plug-in. This includes setting the Encoder Settings to 320KBps! (Reduces delay)
b. Began streaming music. To the Shoutcast server that is being hosted on Computer1.
4. Both winamps on each computer:
a. Open winamp --> Preference --> "Output" -->
b. configure direct sound output.
c. Click on the Buffering TAB. Reduce buffering to the minimum. (This reduces delay even further).
5. On computer1, to start it playing, type in web browser: "http://ip_of_computer1/listen.pls"

At this point, both computers are playing from the same source.

NOTE: Using this method, I've been able to reduce the "Delay" between playtime's to at MINIMUM of 2 seconds. I have yet to better it any more....

As people have mentioned, their is the QoS issue...I wonder if we can disable this? :-)

Makes sense that we could....if people can download a file @ 1MB/s....and we're only streaming @ 128KBps or 320KBps...over a LAN connection (100MBps)....there should LESS than a second delay.
Consider pinging a machine with 6.5KB of data per ping. The response on my network is 2ms.

Consider the worse case scenario of streaming: 320KBps (40KB/s)

This means, in the case of a ping, the delay is: 12.3ms.

So...technically..why can't we have FULLY synchronized streaming audio with a delay of 12.3ms? haha

Obviously there's a technical reason. Perhaps eventually we'll make it there.

BUT: We wonder....couldn't it be possible to..instead of synchronizing the STREAM...we could synchronize the PLAYBACK.... ???
Have each computer stream as close as possible to one another...and..in the meantime...the source computer is playing the actual music...it can provide a real-time feedback on where it is in the song..and send that real-time signal to each other listener. Each listener can fast-forward / rewind the song to the pricise location in the song!!

Why not???

[djSpinnerCee]

Never gonna happen -- it's just not possible to synch a SHOUTcast stream -- even between two identical PCs.

The "why" is about 100 things -- the largest is the DNAS and your player buffer -- Something else (a limiting factor?) that you may not think about is the TCP protocol that requires ACKnoledgement, that means that a PC will not accept (ACK) data blocks sent to it until it has checked them and sent an ACK to the sender so the sender can then send more (in english, the sender waits)... this takes time no matter how fast your hardware is.

You cannot change the DNAS buffer size (whatever size it "really" is), and the DNAS only uses TCP, so this part of the delay cannot be challenged.

Other Player/Server combinations (RealPlayer/RealServer comes to mind) can use UDP, or multicast, which "act" more like a real broadcast without the bi-directional error-controlling TCP ACK mechanism, but that's a different animal. The downside of UDP (used by DNS BTW) is a very small packet size (512bytes) and a lack of error control, the downside of multicasting is little support and blocking by routers, since it works like IP broadcasts and can easily flood the internet in the wrong hands.

[go_latex]

delay affect my titles

ok, sorry if i posted somewhere i shouldn`t have or REPOSTED a question already asked, but it`s been a really long night and at first glance it doesn`t show up...

ANYWAYS, here`s my problem: the delay doesn`t bother me since all i want is to listen to my music from wherever i go... problem is, because of the delay... songs get left behind but titles don`t, so if the server is playing i dunno, tune y ,for example, and i`m listening to tune x still because of the delay... THE WRONG TITLE WILL APPEAR since the delay doesn`t seem to apply to the titles and they are real time... It`s a little annoying. i`m using jetAudio to test my radio, if that may be a problem i don`t know...


Again, sorry if i posted already discussed stuff, but i`m very tired. Cheers

[djSpinnerCee]

It depends WHERE you are getting the tile from:

In the YP the now playing is almost always behind the real time title because it is only "touched" every 5 minutes by the DNAS. The listener is often behind this title such that the now playing has already played.

If you get the title from the DNAS it is in real time and the listener is behind this as well, but not as far behind as the YP.

The DNAS sends metainfo to the player every 8k bytes along with the stream -- if the player supports SHOUTcast, this will be acccurate with respect to what they are actually listening to -- this should be your reference, as it is NOT delayed (actually it is delayed the same amount as the stream audio).

This means that because of the delay, you cannot rely on the YP or the DNAS to know with any certainty what you will hear as a listener, you just have to listen, and you will know for sure. Moreover, that means that you cannot know for sure what a particular listener is listening to based upon the real time track reported by the DNAS -- not a bug, just the way it is.

FYI: Windows Media Player does not support track title streaming (metainfo), making it a bad choice for testing.

[nikosvl]

I had the same problem with you my friend and i solved with a simple way... I have shoutcast v1.9.8 and i play music with virtual dj.My delay it was 20 sec and maybe more and i doesn't want that show i change the Encoding Quality(bitrate) to 160kbps and more on virtual dj and now i have 5 seconts delay.I have 14Mbps download and 1 Mbps upload speed i thing tha it's ok for Q&A to your radio!!!!sory for my Engish :/ i hope i helpd!!!

[DrO]

or (rather than bumping 9 year old threads), you should use the currently available 2.x DNAS which has options for helping to reduce the delay by allowing the buffers to be reduced (though that can compromise the stability of the stream). as well as by default it working out buffers that are based on time than data size (which is how your "fix" works as you're just filling up the buffer soon when using a higher bitrate).

either way, please look at when a thread was last posted in before posting.