[arm-allstar] Broadcastify

[Patrick Perdue]

Broadcastify has a pre-buffer. I don't know for sure, but I expect it is 
128K, which would be a little over a minute at 16 kbps. Combine that 
with the low bitrate and that's where the delay comes from. At a higher 
bitrate, the buffer would fill up faster, and the delay would be less.

This is why I also run a second feed at 64 kbps on my own icecast server 
with no prebuffer, which is also attached to an Amazon echo skill. 
Usually, I feed this from a hardware fob for even less delay, but it's 
currently being fed from nptee, and the delay is about 42 seconds to my 
64kbps feed, and I don't know what the Broadcastify one is doing. From 
the sound fob, I've had the delay as low as a second coming back to me 
from the Icecast server.

The delay is increased if you use nptee between app.rpt and 
lame/ezstream as opposed to feeding lame/ezstream directly from 
outstreamcmd.

I have thought about experimenting with darkice, snd-aloop and aplay 
from app.rpt to get local latency to Icecast down, but I've yet to 
actually do it. I use aplay on one of my nodes to pipe the output to the 
Raspberry Pi's built-in audio jack for local monitoring purposes. There 
is about 100ms or so between audio to a radio via a fob and the output 
from the Raspberry Pi.


On 12/30/2022 1:16 PM, Ken via ARM-allstar wrote:
> My feeds used to have a 40-second delay.  I checked today and right now it
> is up to 1 min 40 seconds - or 100 seconds.
> I expect essentially all this delay is inside Broadcastify and it is what
> they need to reliably support a continuous stream of data to all listeners.
>
>
> Ken
> KE2N
>
>
>
> _______________________________________________
>
> ARM-allstar mailing list
> ARM-allstar at hamvoip.org
> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>
> Visit the BBB and RPi2/3/4 web page - http://hamvoip.org