Asl3 - ezstream auto reconnect / nptee alternative

AllStarLink
1

I’ve been migrating from hamvoip to ASL3. One of the things I have setup is ezstream. I’ve setup using these directions: Streaming Node Audio to Broadcastify - AllStarLink Manual

The problem I run into is if there’s a network hiccup - ezstream will toss a socket error, show it reconnected, but broadcastify will show it offline. I have to restart asterisk to resume.

Aug 31 09:58:21 r145 ezstream[317456]: connected: http://audio9.broadcastify.com:80/redacted
Aug 31 09:58:21 r145 ezstream[317456]: streaming: standard input
Sep 01 01:18:27 r145 ezstream[317456]: stream: default: send: audio9.broadcastify.com: error -4: Socket error
Sep 01 01:18:27 r145 ezstream[317456]: reconnect: audio9.broadcastify.com: attempt #1 ...
Sep 01 01:18:27 r145 ezstream[317456]: reconnect: audio9.broadcastify.com: success
Sep 01 01:18:27 r145 ezstream[317456]: streaming: standard input

Under hamvoip, they have a tool called nptee that can use pipes to give a bit of separation from asterisk and ezstream. This was done mainly so that a socket error wouldn’t block restart of asterisk, but it also makes it useful to restart. I would restart ezstream process itself (and I could even do a script to check the status with broadcastify).

There is no nptee in ASL3. I could try compiling it for ASL3, but wondered if there other solutions that people have come up with.

2

The source for NPTEE is available somewhere on HamVoIP’s website. I have not used it on ASL3, but I did use it for a while on ASL 1.01.

I must confess that I’m still using HamVoIP to stream to two different servers – broadcastify and my own custom Icecast server at a higher bitrate with much less delay, which is attached to an Amazon Alexa skill. I’m not using NPTEE, though, because it adds a bunch of latency. I have each stream connected to a private node. I never have to touch it. If the connection to Broadcastify or my own local server breaks, it silently retries in the background and doesn’t seem to do anything bad, as is apparently the case with ASL3, which I haven’t tried using for this purpose since the beginning of ASL3’s release.

3

Can you please clarify what you mean by this? ASL doesn't distribute or modify sox or ezstreamer so any problems with ezstreamer behavior isn't ASL's fault to fix but it would be good to know what behavior you're seeing. I've had no problems with my standard setup.

4

Maybe I should have put this in 3rd party software. ezstream is installed by default on the ASL3 image, but it’s probably not supported at the same level as say, asterisk. I don’t think its specifically an ASL issue, but I

Anyways - what I see is that if there’s a disconnect, then broadcastify will report is as offline; even if the log entry reports success reconnecting. I have to restart asterisk so it re-runs the ezstream command.

Next time it happens, I may try sending it a SIGUSR1

  Triggers rereading of metadata for the stream by running the configured program or script.  This  is
            the only meaningful signal when streaming from standard input.

My current setup follows the doc page pretty closely:

outstreamcmd = /bin/sh,-c,/usr/bin/lame --preset cbr 16 -r -m m -s 8 --bitwidth 16 - - | /usr/bin/ezstream -qvc /etc/ezstream.xml

ezstream.xml

<ezstream>
    <servers>
        <server>
            <protocol>HTTP</protocol>
	    <hostname>audio9.broadcastify.com</hostname>
            <port>80</port>
	    <password>redacted</password>
            <tls>none</tls>
        </server>
    </servers>

    <streams>
        <stream>
		<mountpoint>/zredacted</mountpoint>
            <format>MP3</format>
	    <stream_name>BCARS.org 145.490 MHz Linked Repeater</stream_name>
	    <stream_url>https://wwww.bcars.org/</stream_url>
                <stream_genre>Amateur Radio</stream_genre>
		<stream_description>145.490 Bedford/Kinton</stream_description>
                <stream_bitrate>16</stream_bitrate>
                <stream_channels>1</stream_channels>
                <stream_samplerate>22050</stream_samplerate>
                <stream_public>Yes</stream_public>
        </stream>
    </streams>

    <intakes>
        <intake>
            <type>stdin</type>
        </intake>
    </intakes>
</ezstream>
5

Unfortunately, ASL doesn't support ezstream at all. In fact, I was marginally surprised it's still in Debian 13 Trixie because the code's been untouched/unmaintained for five years. The Broadcastify/RadioReference "Pi Appliance" uses the newer Darkice streamer. From what I've seen, Darkice can read raw PCM audio from from a named pipe and deliver it directly to Broadcastify. You could create the pipe in advance with mkfifo or have a small C or Python program that creates it (as needed) and just copies the PCM audio from outstremcmd's stdin to the named pipe.

"Do something better for Broadcastify" is theoretically on a list somewhere, but if anyone has a strong interest in the topic and wants to come up with a modern, workable solution that's robust I'm sure we'd update the documentation.

One comment I will make is the solution cannot include nptee since that is not, to my knowledge, open source software with a compatible license.

6

FWIW, sox, ffmpeg, and pipectl are all possible things for the outstreamcmd= command to write to a FIFO.