45SigSauer
Member
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.
Delay in broadcast
- Thread starter 45SigSauer
- Start date
- Status
dwh367
Member
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
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
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
@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.
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
Is there another "scanner remote-audio package" out there besides mine?
You did purchase a license from me.
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:
Sorry, Peter, my bad.
f1r3mans
Member
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?
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
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
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
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.
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
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:
- What type of scanner are you using?
- If you're running a Uniden scanner, what speed is the COM interface set to?
- 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?
- Are you experiencing many disconnect events? Check the ScannerCast log...
- 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:
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.
If RR.com is using icecast they can make server changes to reduce the delay to 3-5 seconds.
- Status
