This would kind of make sense, phones use the RTP protocol for audio is designed for real-time communication and so, naturally sync with each other in a local network.

As a proof of concept, I wanted to create a service that allowed me to “dial-in” to a radio stream on demand…

Initial thoughts was to just to pipe a continuous radio stream to an extension. However, in addition to the waste of bandwidth, any network disruptions would essentially kill the stream without recovery. Therefore, a play on-demand service would help keep the stream fresh whilst saving bandwidth at idle.

My preferred radio for testing is Kerrang radio, I get the URL’s for radio feed via this site and downloading the playlist .pls file, then opening the file in a text editor to extract the actual stream URL.

Baresip Setup

Similar to the earlier project in piping audio from a Raspberry Pi to SIP, a minimal install of Baresip will be used to handle the SIP element and added as a system service in a mostly similar way.

To give the script some context on when to play on demand, we need a log of baresip’s output.

In the service configuration file, under [service] change the following line:

ExecStart=/usr/bin/baresip

to:

ExecStart=/bin/bash -c "/usr/bin/baresip > /path/to/sipaudio.log 2>&1"

This will now run the application and send all output to a sipaudio.log file for processing by the script.

Script

The script will read the log file for any newly established calls and add them to a counter to establish how many calls are active, while the call count is greater than zero, trigger the radio stream.

Similarly, call terminations are also registered and affect the active_calls variable.

The goal is to ensure the stream is only triggered when the first active call is dectected, and only stop the stream when the last remaining call is cleared down.

For example, if Phone A calls in, the stream is triggered and starts playing. Then, phone B also calls in and hears the established stream. If Phone A was to hangup, we’ll need to continue the stream for phone B (i.e not latching to the phone that triggered the stream), but if phone B also hangs up, the stream is stopped as there’s nothing there to listen.

Create the script file and add the following:

#!/bin/bash

# Path to Baresip log file
LOG_FILE="/path/to/sipaudio.log"
STREAM_URL="http://edge-bauerall-01-gos2.sharp-stream.com/kerrang.mp3?aw_0_1st.skey=1736072895"

# Track active calls
active_calls=0
mpv_pid=""

start_stream() {
    if [[ -z $mpv_pid ]]; then
        echo "Starting stream..."
        mpv "$STREAM_URL" &
        mpv_pid=$!
    else
        echo "Stream is already running."
    fi
}

stop_stream() {
    if [[ -n $mpv_pid ]]; then
        echo "Stopping stream..."
        kill $mpv_pid
        wait $mpv_pid 2>/dev/null
        mpv_pid=""
    else
        echo "Stream is not running."
    fi
}

monitor_calls() {
    echo "Monitoring Baresip log for call events..."
    tail -Fn0 "$LOG_FILE" | while read -r line; do
        if [[ "$line" == *"Call established"* ]]; then
            ((active_calls++))
            echo "Call incoming. Active calls: $active_calls"
            if [[ $active_calls -eq 1 ]]; then
                start_stream
            fi
        elif [[ "$line" == *"session closed"* ]]; then
            ((active_calls--))
            echo "Call ended. Active calls: $active_calls"
            if [[ $active_calls -le 0 ]]; then
                active_calls=0
                stop_stream
            fi
        fi
    done
}

# Start monitoring calls
monitor_calls

Make the file executatble with:

chmod +x /path/to/filename.sh

Service

This can be ran via the terminal/SSH, but for ease of use and reboot survival, lets create a service for the script.

Create and edit a service file:

sudo nano /etc/systemd/system/sip.radio.service

Add the following to the new service file:

[Unit]
Description=Kerrang Radio Stream
After=sound.target network.target

[Service]
ExecStart=/path/to/filename.sh
Restart=always
RestartSec=10
User=pi
WorkingDirectory=/home/pi
StandardOutput=journal
StandardError=journal
Environment=HOME=/home/pi
Environment=XDG_RUNTIME_DIR=/run/user/1000

[Install]
WantedBy=multi-user.target

When saved, reload services:

sudo systemctl daemon-reload

Start the service and enable it to start at boot:

sudo systemctl enable --now sipradio

Now a test call can be made to the baresip extension, and hopefully the radio will be though in a second or two.

Summary

Since originally starting this in March, the script and SIP endpoint has been idle for a few months, but seeing if it still works while writing this, the stream fired right up on first asking.

I would like to significantly reduce my “smart” speaker density, as they are almost exclusivley music players at this point due to the frustration in using them for anything else (even playing music is a challenge at times), but are always listening in.

To put this theory into production will require both opus capable phone hardware and decent wired/bluetooth speakers with connectivity inbetween.

I wonder if a Pi Zero W2 could come to a cheap option rescue?

With no speakers connected this can sometimes pose an issue when trying to follw a tutorial video, and when I do need audio, a Bluetooth speaker is never around.

There is a SIP phone next to the Pi on my desk, and so I thought; that has a decent network connected speaker, why not use that?

This is what ensued…

The idea is to have a SIP endpoint running as a service on the Pi in auto-answer mode. This will allow a desk phone to dial the Pi extension and receive the Pi’s audio through the loudspeaker.

The Pi is running stock Raspbian Bullseye with the desktop environment.

SIP Endpoint

Baresip looks a good choice for this project due to its modularity.

As this will be a service running in the background, only the core module of Baresip needs to be installed:

sudo apt install --no-install-recommends baresip-core

When installed, run the program briefly to have it create its default configuration files:

baresip

This will create the default template files in a .baresip directory within the home folder. We’ll need to edit the accounts and config files to get it to a call answering state.

Starting with the accounts file:

nano .baresip/accounts

Add the following line to the bottom of the file:

<sip:{endpoint}@{sip_server}>;auth_pass={sip_secret};answermode=auto

Where:
{endpoint} – SIP extension number
{sip_server} – IP/hostname of the PBX
{sip_secret} – Extension password

Answermode flag has been added to allow calls to this extension to be answered automatically.

After the accounts file, move onto the config:

nano .baresip/config

This file can be left as default, however a few quality-of-life improvements will be made…

Uncomment the following lines:

module                  opus.so
module                  g722.so

These allow the use of the higher quality codecs commonly in use; g722 is the elder and while it offers higher quality from a phone call audio point of view, may fall short for music. Opus is the newer and can be configured for excellent quality overall, but being newer may not be an available choice on older phones.

If Opus is available, the bitrate can be increased via this line further down the config file (higher bitrate, higher audio quality):

opus_bitrate            28000 # 6000-510000

Make sure both you SIP devices and PBX are capable and configured to offer these codecs at the highest priority.

Testing

Good time for a sanity check, for this an audio file or stream playing through VLC, or any source of audio will do.

Run the application in the terminal

baresip

And make a call to its extension, you should see output in the terminal, and hear the audio through the phone.

If it’s successful, a service can be created to have this running in the background on startup…

Create Service

To allow baresip to start at boot, its best to create a service for it and restart it if it ever stops.

Create and edit a service file:

sudo nano /etc/systemd/system/sipaudio.service

Add the following to this file:

[Unit]
Description=SIP endpoint for Pi audio
After=sound.target network.target

[Service]
ExecStart=/usr/bin/baresip
Restart=always
User=pi
WorkingDirectory=/home/{username}
StandardOutput=journal
StandardError=journal
Environment=HOME=/home/{username}
Environment=XDG_RUNTIME_DIR=/run/user/1000

[Install]
WantedBy=multi-user.target

When saved, reload services:

sudo systemctl daemon-reload

Start the service and enable it to start at boot:

sudo systemctl enable --now sipaudio

With some audio playing, try another call to make sure its answering and picking up audio from the desktop environment.

Conclusion

It’s a niche solution for those who have an audio-less Pi and a SIP phone next to it, but the results are plesently convenient for those rare times when audio is needed.

My accompanying desk phone (Yealink T46S) only offers g722 has the higher codec, but still is perfectly fine for speech output and fine (not great) for audio. I’m sure using Opus at the higher bitrate will put it on par with some of the streaming services. Afterall, YouTube uses opus as audio for its videos, as noted by the “stats for nerds” section:

A Linux system has always had the impression that it is versatile, so this should be an achievable task. A barrier would be how to get this done with the operating system installed, in this case it is LibreElec, an OS with the tagline “Just enough OS for Kodi”. Therefore, it would be more of a challenge than a usual Debian install.

The team at LibreElec saw this type of thing coming, and included the Docker service as a Kodi addon to allow the curious tinkerer to add more than Kodi to a Pi.

If you have the LibreElec based Pi in the opportune placement to add a camera, here is how to add Mjpeg streaming capabilities…

Add the Addons

Via Kodi on the screen, goto:

Addons --> Install from Repositories --> Services

Then install the two addons required:

RaspiTools
Docker

CLI Access

To setup Docker and its container (the Mjpeg streamer) requires Command Line Interface (CLI) access to the Pi, if not already enabled during setup enable it via Kodi by navigating to:

Settings --> LibreElec --> Services --> SSH

Mjpeg streamer

The M-Jpeg-streamer is a well-used Linux library, and have chosen the Open-Horizon version of a Docker image for this task.

Log in to the Pi via SSH and run the following:

docker pull openhorizon/mjpg-streamer-pi3:latest

Follow the prompts and be prepared to wait as the Docker image builds.

When complete, start the Docker container with:

docker run --restart=always -it -d --privileged -p 8081:8080
openhorizon/mjpg-streamer-pi3 ./mjpg_streamer -o "output_http.so -w
./www" -i "input_raspicam.so -x 1280 -y 720 -fps 10 -ex night"

This code explained:

docker run: start a Docker container
–restart=always: Restarts a container if the system is restarted
-it: allocate a pseudo-TTY for debugging and to stop it.
-d: Run in background, enables CLI to exit without stopping container.
–privileged: Give privileges that allows access to the camera.
-p 8081:8080: Translate streaming port from 8080 to 8081, as not to conflict with Kodi.
openhorizon/mjpg-streamer-pi3 ./mjpg_streamer: name of Docker image.
-o “output_http.so -w ./www”: internal reference.
-i “input_raspicam.so -x 1280 -y 720 -fps 10 -ex night”: Camera settings, set resolution, frames per second and Pi camera filters.

Run

The Docker container should now be running, check this by entering this in the CLI:

docker ps -a

To show running containers.

Now you can access the web GUI by visiting http://ip_address:8081 to test.

From here it can be added as a Network Camera to MotionEye.

Configuration

During setup its important to consider the hardware it running on. This was running on a Wi-Fi only Raspberry Pi 3A+, while it’s processing power was more than adequate for my initial setup of 1920×1080@20fps this saturated the network connection, leaving no bandwidth left to stream the media LibreElec was designed for. The reduction to 1280×720@10fps reduced the active bandwidth enough as not to interrupt the media players primary function.

Looking for a CCTV project earlier this year I too was drawn in by this, and with my small abundance of RPi spares it was the cheapest choice, using a couple of RPi 3B+ for video, and a Zero W for time-lapse image capture. All processing was self-contained on each Pi with capture data passed over via SMB to a Windows file share.

This worked, but had a couple of problems that prevented it from being trustworthy. Firstly, it stops recording video after a few days of uptime, by creating empty files. And secondly the time-lapse camera seemed to reset every few minutes that created in white out image capture as the camera’s exposure setting recalibrated, ruining a time-lapse video.

Looking wider there was also the performance issue. In Motioneye OS’ default state of managing all features, the highest FPS seemed to max at 15 fps even on the Pi 3B+. Forums suggest this is due to the motion eye daemon handling all the image processing in software, putting a strain on the Pi’s modest CPU.

The idea and goal is to move the processing and IO responsibilities to my server, which would be far more capable than the then latest available RPi, and as I have chosen Cent OS to be my go-to Linux OS of choice, this is what I’ll be using.

A gateway to make this possible is an option in Motioneye OS, Fast Network Camera. This when set relinquishes the Pi of all processing duties and serves to just stream the camera capture as best as possible via MJPEG.

Here’s how to set up Motioneye on a Cent OS server to be a central data hub for a network of RPi Motioneye OS cameras.

OS Setup

In this VM setup two drives (VHD) are allocated, a 16GB drive for the OS, and a 2.6TB drive to be manually mounted and used solely for capture storage. Both VHD’s are contained on the same single 3TB 6Gbps SATA drive.

Run the Cent OS install wizard, choosing just the 16GB drive as the install destination. Its also helpful at this stage to configure a static IP for easier locating.

On successful setup and reboot, login via SSH and enter fdisk -l to discover the location of the large disk.

As the disk is larger than 2TB, we need to use the parted command to create a GPT disk format, in this case enter

parted /dev/sdb

Within the parted command, enter this to create the file system.

mklabel gpt 

Assign the size of the partition to use the entire disk (referenced from the earlier fdisk -l command).

mkpart primary 0GB 2858GB 

Exit parted.

quit

Format the new partition to make it usabl.

mkfs.ext4 /dev/sdb .

To use this new drive it first needs to be mounted to the sile system, and to do this it needs an entry point. Add a new folder as the entry point then mount the new drive to it.

mkdir /cctv
mount /dev/sdb /cctv

Check to see if its connected

df -h

This drive link will not work after a reboot, to do this the /etc/fstab file needs to be added to.

My file editor of choice is nano, so I enter this to start editing:

nano /etc/nano

Nano is not available with the minimal install of Cent OS, to install, enter yum install nano, follow the prompts and nano is installed.

Add the following:

/dev/sdb    /cctv     defaults              0 0

Then save and exit.

Ctrl +O 
Ctrl +X

Cent OS prerequisites

The Motioneye Install Guide had options for a number of Linux distributions but Cent OS is not listed. The closest match is Fedora which like Cent is based on the Red Hat architecture. To mimic a fedora install a couple of Repository libraries need to be added so the OS can find the install files, enter the next two commands and accept the prompts to add:

yum install epel-release

yum localinstall --nogpgcheck https://download1.rpmfusion.org/free/el/rpmfusion-free-release-7.noarch.rpm https://download1.rpmfusion.org/nonfree/el/rpmfusion-nonfree-release-7.noarch.rpm

 Motioneye Install

Before Motioneye can be installed it needs the supporting software to be installed beforehand/

yum install motion ffmpeg

Install the building language and associated software:

yum install python-pip python-devel gcc libcurl-devel
pango-devel

Now to download and install Motioneye:

pip install motioneye

Create the operating folders and copy the configuration files to their intended location:

mkdir -p /etc/motioneye

cp /usr/share/motioneye/extra/motioneye.conf.sample /etc/motioneye/motioneye.conf

Edit the motioneye.conf file to utilise the 2.6TB drive for storage:

nano /etc/motioneye/motioneye.conf

Edit the following line:

Ctrl+O to save and Ctrl+X to exit

Enable Motioneye to run as a service and to start at boot, and start it for the first time:

 cp /usr/share/motioneye/extra/motioneye.systemd-unit /etc/systemd/system/motioneye.service

systemctl daemon-reload 

systemctl enable motioneye

systemctl start motioneye

Samba Setup

To enable easier access to the footage, installing Samba allows Windows machines selective access to the Linux file system.

Install the samba service:

yum install samba samba-client samba-common

Make a backup of the config file in case anything goes wrong:

cp -pf /etc/samba/smb.conf /etc/samba/smb.conf.orig

Use nano to edit the config file:

nano /etc/samba/smb.conf

Remove the default setup and replace with the below. This creates a network share with access to the cctv folder, allowing Linux users in the “smbgrp” group access to it:

[global]
        workgroup = WORKGROUP
        security = user
        passdb backend = tdbsam
        printing = cups
        printcap name = cups
        load printers = yes
        cups options = raw
[cctv]
        comment = Camera Store
        path = /cctv
        valid users = @smbgrp
        force user = root
        browseable = Yes
        read only = No

Now lets add a new user and give it secure access to the cctv folder.

Create the access group:

groupadd smbgrp

Add the user and assign it to the group:

useradd cctv -G smbgrp

Set the password for the new user:

smbpasswd -a cctv

Next to amend the permissions of the cctv folder to grant access via Samba:

chmod -R 0777 /cctv
chcon -Rt samba_share_t /cctv

Time to set Samba to start on boot, and start for the first time:  

systemctl enable smb.service
systemctl enable nmb.service
systemctl start smb.service
systemctl start nmb.service

From a Windows machine, navigate to the server and check that the folder is accessible.

Firewall

Lets allow access to MotionEye and Samba from the outsode world (including local network) by editing the firewall:

MotionEye needs port 8765 opened to allow setup and administration:

firewall-cmd --add-port=8765/tcp –permanent

Samba is a recognised service, so this can be allowed by entering:

firewall-cmd --permanent --add-service=samba

Commit these changes by entering:

firewall-cmd --reload

Testing

From here and all things well, the MotionEye frontend should be available by visiting the server at http://server_ip:8765 .

Login with a username of admin and entering no password, which takes you to the familiar Motioneye GUI.

Camera Setup

Server now running the Pi Camera units need configuring / reconfiguring to be accessible to the server.

From Motioneye OS on the Raspberry Pi, login to access the settings options, navigate to General Settings and toggle on Advanced Settings. Click Apply.

Now navigate to Expert Settings and toggle on Fast Network Camera, click Apply.

Logging in again after the system reboot everything looks the same initially, but now capture controls are replaced with just Video and Streaming controls, and this does give more access to the finer details of the camera.

In the Streaming section, the stream port and authentication can be set. Authentication is not required, but is recommended if the server is on a shared network, as the footage will be available to view on any device on the network.

The streaming section also reveals the Stream URL, which is need to add the camera to the server…

Adding Cameras to Motioneye Server

Log back in to the Server’s Motioneye frontend, click the No Cameras dropdown box and choose Add Camera.

Choose Network Camera from the next dropdown box and add the streaming URL of the Pi camera to the address field, and credentials if set on the Pi. If correct the Camera field will auto populate:

Click OK to add camera. From here the familiar capture storage options are now available and configurable.

Additional cameras can be added in the same way.

Tweaking

Setup does require revisiting in the first few days to ascertain how many days footage can be retained before drive space runs out, if it does, MotionEye will stop recording. I had the benefit of setting this up during the height of summer, where the longer daylight hours create more capture data to store. As the nights draw the storage requirements per day will reduce.

Since the raw MJPEG video stream is being pulled by the server over the network as opposed to a data file, its worth considering what impact this will have on your network. To find out how much data is flowing iftop is a tool available on Cent OS to visualise this, to install run:

yum install iftop

Then run with:

iftop -n

Iftop shows data flow rates per IP address and gives 1min, 5min and 15min stats akin to uptime. From the screenshot above we can see the cameras are averaging between 30 and 50 Mbps, with a total of 160Mbps of the network utilised for the CCTV system.

This was based on 4 cameras, with larger setups it may be worth exploring a more robust network layout including additions like a all wired setup and configuring extra switches to reduce bottlenecks on the internal network.

Results and further research:

The functionality of this setup is great and far better than the previous where the Pi’s were doing all the processing work. Stability is much improved with the reliability of video capture and the increased frame rate, comfortably keeping 20 fps. And time-lapse images have a uniform brightness throughout which makes them much smother after processing.

Issues to work on following this install is that images fail to load in the MotionEye GUI, this can be overcome by someone used to the GUI but for newcomers the absence of login and slider icons can be confusing.

Raspberry Pi 3A+

The Pi 3A+ plus is the cut down little brother to the latest 3B+ much akin to the original Pi B and A models. Both have the same quad-core ARM v8 processor, Broadcom Videocore-IV GPU and importantly the 2.4GHz and 5GHz 802.11b/g/n/ac Wi-Fi module for faster and stable WIFI out of the box. What’s cut down is the RAM, halved at 512MB, USB ports are reduced to one due to the removal of the onboard USB and gone is the ethernet port.

All the power without the ports make its perfect as a media player, all that’s needed to connect is the HDMI, with remote control provided via a CEC equipped TV.

The issue with OSMC

Here are the issues I experienced with OSMC on the Pi3A+, this is in no way a snarl at the developers who are doing an amazing job. I believe the 3 A+ is still a new and niche model so it’s understandable that development is slow for this product. I’m just hoping this will eventually be looked into and resolved, and putting it out there in case others have the same issue. Performance on the 3B+ is still exceptional.

From boot, selecting a 720p file (via Samba and h264 encoding) is fine, with subsequent auto-play files playing with no issues. However, with the next selection the issues start, selecting a file loads it but doesn’t play, having to go to the main menu and selecting Full-Screen to play the file. But then it buffers constantly. On the third play this workaround fails, and selecting Full-Screen results in a black screen.

In addition, even from boot any 1080p content fails to play with a black screen in its place, and playing h265 encoded files results in an immediate system crash.

480p content remains unaffected and plays perfectly.

LibreELEC to the rescue

Without resorting to buying a 3 B+, your media experience can still be made on 3 A+ by using LibreELEC, an alternative to OSMC that has the same goal of getting Kodi on the Raspberry Pi.

This distro gives the exact same experience, assuming you use the Kodi default Confluence skin and not the custom default on OSMC.

Installation is just as easy with installer package available on Windows, however its not as refined as the OSMC equivalent, first there is no option to pre-configure the wireless settings needed on the Pi A models, but is included in the setup wizard when booting up on your TV.

Second, and the point if this post, the Windows installer as problems overwriting SD cards with an existing file system, and gives a write error before the program hangs.

To overcome this, the SD card needs to be purged of its previous partitions:

In a File Explorer window, right click This PC and click Management

In Computer Management, click on Disk Manager

Identify the SD card in the lower graphic, the best way to achieve this is to match the drive capacity of the SD card, in this case it is the 8GB drive.

Right click every allocated partition, identified by the upper blue band, and click delete volume.

When complete, the drive will look like this.

From here, re-run the installer and choose the drive that matches the SD card capacity, the installer should now write to the card with no issues.

LibreELEC in action

If you are moving from Pi 2/3 B model to a 3A+ then it’s business as normal, 1080p h264 files, and up to 720p h265 files play without issues. Although those hoping for 1080p h265 encoded playback will be eternally disappointed given that this exceeds the Pi’s hardware capability.

One curious note for a UK resident, there is no regional setting for the United Kingdom, so have to resort in using an Isle of Man profile to get the correct time, and manually setting the region variables.

Only niggle in my head was that the card I put Raspbmc on was 8GB, and that bigger card would be put to better use in my camera that was using a 4GB card. I thought it would be no problem to reformat cards and swap them over?

Wrong!

The 8GB in the camera was fine, and I used the Raspbmc installer as before to load it on the new SD card. The trouble was that when first booted up the Pi, it seemed to freeze on the

Sending HTTP request to server

No problem I thought, hop on my laptop and find out if other users experienced the same. But low and behold the internet on my laptop ceased to to work, with strange requests for proxy passwords to sites like Facebook and even the Weather gadget on Win 7!

First thoughts were that I cooked my router, as I been downloading a lot and on a warm day to (yes there was a warm day … I think!). But after it was off for as long as I could stand, powered it back on and normal service was resumed.

After rebooting all network equipment it finally dawned that the internet would go down for everything connected to my network when the Pi was powered up! I had never experienced this before and could not for the life of me fathom it out. I thought that it had a defect in the Pi meant that some sort of power surge was knocking out the system? This was quickly dismissed as local traffic was unaffected, meaning the network hardware was operating normally.

A quick glance at my Sky broadband supplied Sagem F@ST 2504 modem showed the internet connection had failed, with the internet indicator glowing orange with a red pulse every second. Stranger still, upon unplugging the Raspberry Pi, connection to the net restored within  seconds!

So how can a network device have the ability to target and destroy an internet connection? Its my understanding that a Pi has no ability to retain settings other than whats stored on a SD card, but this issue continued when using two different memory cards.

Drilling down to an extreme form of troubleshooting, all network devices, including my second switch/access point was disconnected from the Sagem router. leaving just the Pi connected. Then from Midori on Debian Squeeze (remembering that the internal network was unaffected) rebooted the router using the web interface.

Suddenly the Pi could connect, attaching my whole network back together I found that everything was back to normal,

Laptop, Pi, iPhone, everything!

And this is the worst thing, I don’t know what caused this, and what I specifically did in the reboot process that solved it?

So I would love to hear if this has happened to you, and if there was something you can pinpoint as the issue? This one has got me completely stumped!