Delay in broadcast

Status
Not open for further replies.

45SigSauer

Member
Joined
Oct 20, 2007
Messages
150
Location
Lowell, IN
Is it normal for there to be a delay in my broadcast, For instance, I can be looking at my 2055, see there is traffic, but wont hear it on RR for several seconds, I think about 5-10 seconds, it's no big deal, just curious.
 

dwh367

Member
Joined
Mar 17, 2003
Messages
399
Location
Owensboro, KY (Daviess County)
Is it normal for there to be a delay in my broadcast, For instance, I can be looking at my 2055, see there is traffic, but wont hear it on RR for several seconds, I think about 5-10 seconds, it's no big deal, just curious.
That's normal and actually not bad latency at all. When I first started streaming, using Shoutcast, the delay was anywhere between 60 and 90 seconds. It like to drove me up a wall!
 

PeterGV

K1PGV, ScannerCast author
Joined
Jul 10, 2006
Messages
753
Location
Mont Vernon, NH
It depends on the software you use for streaming and the audio client that you use.

Winamp lets you adjust the amount of buffering. More buffering = more delay.

Note that you really WANT a reasonable amount of delay, at LEAST several seconds, and more buffering is generally better than less -- 5 or 10 seconds in minimal, 20-40 seconds is better. Even more if you're on a wireless connection. This is because audio data can be delayed, sometimes by a long time, travelling from RR's servers to your audio player. If you have too LITTLE buffering, that means your playback will break up, stop, and lose audio chunks. Very unpleasant. I had this experience with another scanner remote-audio package I used and it's partly what drove me to write ScannerCast.

Peter
K1PGV
 

ProScan

Member
Premium Subscriber
Joined
Jul 2, 2006
Messages
3,525
Location
Ontario, Calif.
It depends on the software you use for streaming and the audio client that you use.

Winamp lets you adjust the amount of buffering. More buffering = more delay.

Note that you really WANT a reasonable amount of delay, at LEAST several seconds, and more buffering is generally better than less -- 5 or 10 seconds in minimal, 20-40 seconds is better. Even more if you're on a wireless connection. This is because audio data can be delayed, sometimes by a long time, travelling from RR's servers to your audio player. If you have too LITTLE buffering, that means your playback will break up, stop, and lose audio chunks. Very unpleasant. I had this experience with another scanner remote-audio package I used and it's partly what drove me to write ScannerCast.

Peter
K1PGV
That’s not true Peter as my ProScan ScanCast was under development the same time as your ScannerCast so you couldn't possibly known about ScanCast.

I think you must have been referring to the Remote Scanner Over IP feature of ProScan which is designed for real time audio.

ProScan ScanCast does not buffer the audio just like EdCast, SimpleCast, or any other source client does not buffer the audio. Buffering should be done at the end point, not at the source point. That's why media players buffer the audio.
 
Last edited:

PeterGV

K1PGV, ScannerCast author
Joined
Jul 10, 2006
Messages
753
Location
Mont Vernon, NH
That’s not true Peter as my..
@Bob... Did I mention your software, Bob? I don't think so.

Because, to be absolutely, positively, clear I was not talking about ProScan ScanCast. I've never used it, and in fact know nothing about it. I'm sure it's a fine piece of software.

Buffering should be done at the end point, not at the source point.
Actually, buffering needs to be done at both ends, source and client. Buffering at the source allows you to completely decouple your source data stream (the audio and tags from the scanner) which is both constant and periodic, from your "push" and"pull" data streams (data going to RR or to directly connected clients). This provides numerous advantages (quick burst pre-loading for clients, better tolerance to communications delays and failure, etc).

But I'm sure nobody wants to hear us discuss the esoterica of real-time audio streaming software development. Feel free to email me if you like, I'd be very happy to continue the discussion one-on-one.

Sorry if you misunderstood my post, Bob.

Peter
K1PGV
 

ProScan

Member
Premium Subscriber
Joined
Jul 2, 2006
Messages
3,525
Location
Ontario, Calif.
@Bob... Did I mention your software, Bob? I don't think so.
Is there another "scanner remote-audio package" out there besides mine?

Because, to be absolutely, positively, clear I was not talking about ProScan ScanCast. I've never used it, and in fact know nothing about it. I'm sure it's a fine piece of software.
You did purchase a license from me.

Actually, buffering needs to be done at both ends, source and client. Buffering at the source allows you to completely decouple your source data stream (the audio and tags from the scanner) which is both constant and periodic, from your "push" and"pull" data streams (data going to RR or to directly connected clients). This provides numerous advantages (quick burst pre-loading for clients, better tolerance to communications delays and failure, etc).
You may want to add an option to disable the buffering and compare the difference. Why is there no buffering in EdCast and SimpleCast?

Ianier Munoz who wrote the original code that ScannerCast is based on never intended it be used this way. His method buffers the wave capture side but he also uses a callback function which is a big no no so I wouldn't trust his code anyways.

Anyways, this is all in good fun.
 
Last edited:

f1r3mans

Member
Joined
Jun 18, 2008
Messages
2
Location
Maynardville, TN
Delay in Broadcast

12-20-09 at 7:05am ,,,, I just checked to see how long of a delay was in real time dispatch and the RR feed ,,,, It was over 3 minutes? Is that normal? When I first started providing my feed , I noticed a few sec delay, but now it really delayed. Is this something on my end i need to fix?
 

f1r3mans

Member
Joined
Jun 18, 2008
Messages
2
Location
Maynardville, TN
Ok, I rebooted my system , reset my network connection, cleaned all temp files, etc and restarted feed and now the delay is only 6 sec. ??? Guess it was on my end.
 

PeterGV

K1PGV, ScannerCast author
Joined
Jul 10, 2006
Messages
753
Location
Mont Vernon, NH
Sorry, Peter, my bad.
Yes, indeed it is.

We're all helping the community in our own way. There's no need to be so quick to take offense. I don't believe I've ever given you cause to do so.

I won't reply to your comments on software design (especially regarding Ianier, who is a very smart dude and whose code is exceptional, your comments notwithstanding), except to say "Huh??" -- My offer to collegially continue the software design discussion via email still stands.

Peter
K1PGV
 

N2JDS

Member
Joined
Dec 20, 2007
Messages
375
Location
St. Peters, Mo
using K1PGV streamer, getting tags delays

Not the exact same thing, but I am still getting a delay in the tags showing up. The longer it streams the longer the delay. If I stop the tags from streaming and restart, it gets better, but it seems within a few hours it starts to delay again.. Any suggested tweaks. Can I buffer the outgoing stream somehow or something? My audio is maybe 2 seconds or less of real time, so not too bad there.
 

PeterGV

K1PGV, ScannerCast author
Joined
Jul 10, 2006
Messages
753
Location
Mont Vernon, NH
Not the exact same thing, but I am still getting a delay in the tags showing up.
Let's see if we can get you fixed-up :)

I spent some time listening to your feed and watching the tags with a diagnostic program I have... you have one ugly and hellacious delay between audio and tags. I counted a full 8 to 10 seconds, which is weird.

Several questions for you:
  1. What type of scanner are you using?
  2. If you're running a Uniden scanner, what speed is the COM interface set to?
  3. What kind of system are you running (Windows version, CPU speed, memory) and how much CPU time do you have available on that system while ScannerCast is running? What else is going on while you're running ScannerCast?
  4. Are you experiencing many disconnect events? Check the ScannerCast log...
  5. Other than sending your stream to RR, do you have any clients connected directly to ScannerCast?

Theoretically, it shouldn't be possible for tags in ScannerCast to progressively "fall behind" -- The tags are stored at the same time as the audio data (well, taking into account things like the delay through the MP3 encoder and several other things). And there's an algorithm that's suppose to self-adjust if tags get behind in certain circumstances.

Now, I'm not saying there's not a bug in ScannerCast that might account for what you're seeing :) I'm just describing how ScannerCast is supposed to work.

Clearly you've got something unusual happening... it looks like a bug... and I'd sure like to squash it!

Peter
K1PGV
 
Last edited:

webstar22

Member
Premium Subscriber
Joined
Dec 21, 2003
Messages
832
Location
Earth Sector 001
You are providing a online feed. There is no reason why a delay should matter.

If RR.com is using icecast they can make server changes to reduce the delay to 3-5 seconds.
 
Status
Not open for further replies.
Top