[arm-allstar] question on nptee/broadcastify buffering

[John Hogenmiller]

I had a (hopefully) quick question on nptee.  I followed the broadcastify
and nptee pdf instructions on the hamvoip site and got broadcastify
working. It mostly works great and the longest delay was waiting overnight
for radioreference/broadcastify to approve the stream.

What I'm seeing is at least a 2 minute delay from live audio to
broadcastify. Is this expected? I know broadcastify enforces a 20 second
delay.  I read in the PDF that nptee buffers 1 minute of audio.  My
question is if that means that nptee buffers a minute of audio before
sending it to ezstream?

If a two minute delay is not common, are there options to nptee, ezstream,
or lame that could decrease the lag?

For technical context:

My command is almost direct from the PDF:
/usr/bin/lame --preset cbr 16 -r -m m -s 8 --bitwidth 16
/tmp/outsound/broadcastify1 - 2>/tmp/status | ezstream -qvc
/etc/ezstream.xml

I'm running this via systemd which gives me timestamps.  I see data reports
every 2 minutes, 7 seconds. I don't know if this is just how often it
reports to the console, or if it's batching audio up. Most of this time
period was quiet time on the repeater.

Dec 30 09:14:06 r145 broadcastify.sh[1373]: ezstream: Streaming from
standard input
Dec 30 09:16:13 r145 broadcastify.sh[1373]: [1.9K blob data]
Dec 30 09:18:20 r145 broadcastify.sh[1373]: [1.9K blob data]
Dec 30 09:20:27 r145 broadcastify.sh[1373]: [2.0K blob data]
Dec 30 09:22:34 r145 broadcastify.sh[1373]: [2.0K blob data]
Dec 30 09:24:41 r145 broadcastify.sh[1373]: [2.0K blob data]
Dec 30 09:26:48 r145 broadcastify.sh[1373]: [2.0K blob data]
Dec 30 09:28:55 r145 broadcastify.sh[1373]: [1.9K blob data]
Dec 30 09:31:02 r145 broadcastify.sh[1373]: [2.0K blob data]
Dec 30 09:33:09 r145 broadcastify.sh[1373]: [1.9K blob data]

Thanks in advance,
John/KB3DFZ