I just started streaming my hub to broadcastify so that way if either a ham wants to monitor my hub without going through the node building process they can or if a non licensed listener wants to listen to my hub to see if ham radio is a good fit where i carry regular conversations regular nets and ARES/Skywarn practice and real deal nets on my hub they can but i noticed when i was listening and sent a few test audio clips with nothing connected just direct that there’s a large 1 minute 35 second delay from after it went through my hub just to hit my broadcastify feed which to me seems to be little to long i can understand a 30 second delay between the 2 but 1:35 delay to me seems too long so i’m looking to see if there’s a way for me to shorten the delay time between the 2 to make it be at least 30 seconds or less?
i used the ezstream method to host the audio from my hub to broadcastify and it just went online roughly an hour ago so it’s that new
Broadcastify, in my experience, lags realtime audio by about 1-2 minutes with some variations over time. It’s not a solution for near-real-time audio monitoring.
Almost all that delay is from Broadcastify itself.
I host a local Icecast server to minimize latency, then stream to that as well as Broadcastify using two private nodes, each with it’s own outstreamcmd.
Using Icecast with BurstOnConnect disabled, streaming at 64 kbps mp3, I can achieve a delay of less than a second on the same host. Usually no more than a couple of seconds over the internet, conditions dependent on latency.
There’s no way you will ever get anything close to that from Broadcastify. They add a server-side buffer, and it’s a low bitrate over TCP, so clients will do some of their own buffering, which takes longer with less data to process.
I use 64 kbps, because it serves two purposes. It sounds better than 16 kbps, and it’s a faster bitrate, which further cuts down on the delay.
If you’re curious, the stream URL for my system, the Blind Hams Network, is here: http://stream.borris.me:8888/blind-hams
and it is connected to nodes 50631NXX, nodes 0 through 5.
ok what about caster fm is that any good? i know a local GMRS network uses caster fm before the no internet linking on GMRS went into effect but unsure if that has higher delay or lower delay i know regular listener that has no ham experience or has no allstar experience won’t notice but as an administrator of my feed i just find that a 1:45 delay is too long and 30 seconds or less would be the sweet spot
i personally like broadcastify because of the hourly feed archive for paid users so if lets say you missed a net that is being shared on my hub and you are a paid user you can go back to that hour and listen to that net that’s what i like about broadcastify but i personally find that 1:45 delay is too long