Introduction

Nothing works without network anymore. Most people take it as a given and actually won't spend much thought on it. The clients get connected and that'll be it. Usually they work.

Now. Network, either wifi or wired can have an impact on the system performance. Wifi usually puts a lot more load to a system, is much less reliable, and changes with network load and daytime. Beside that it can induce microwaves into your fragile audio environment.

Some people won't get around using Wifi. Let's have a look at it first. Because it's much more tricky then a wired network.

Wifi

Since the beginning of times I vehemently ruled out using onboard-WiFi on my audio streaming clients.

I did it for reasons, such as:

lower and varying performance (bandwidth, package jitter, package loss)
higher noise, EMI/RFI. The antenna sits right below the audio HAT
pretty basic onboard WiFi implementations
rather low performance WiFi chips (single 2.4GHz Wifi band support)
rather low performance antennas
extra load on OS, CPUs and power rails

And then there were and still are the usual environmental challenges that come with WiFi, such as:

router and client locations
time of the day variances
non controllable WiFi band occupation (neighborhood)

Times are changing, while technology is evolving. Earlier made decisions should be revisited once in a while.

I've seen more than once that you have to challenge earlier conclusions, experiences and decisions.

No challenge - No progress!

What do we have actually on the table now?

First of all. Many of above WiFi related issues still apply. Hmmh. No good. Let's call the whole thing off!

...just kidding. As a matter of fact some areas of progress can be pinpointed.

That's how the actual RPI situation looks to me:

the recent RPIs generations (3B/4) are better engineered (layout/heat/power/radiation)
the recent RPIs come with a much better WiFi chip (Cypress CYW43455) then before
they now support 802.11n/ac - which offers access to the less crowded 5GHz band
the new Cypress chip seems to offload en-/decryption tasks off the RPI CPU!
the embedded antenna from Proant - which basically is etched into the board layers - can be considered a real smart high performance design choice (You might want to read this review.)
The trapezoidal shape in below image is the actual antenna. The shielded box below hosts the Cypress Wifi chip.
OK. A nice UFL socket to attach an external antenna would have been the - to me - perfect solution.

There are also some universal advantages using WiFi we shouldn't forget, such as:

the galvanic isolation starts on-board
cabling, routers, NW bridges, related power supplies etc. can be removed to a certain extent
(RPI 3B!) with WiFi we don't use the still rather mediocre RPI USB stack incl. ethernet

Additionally the evolution in the audio HAT market contributes its share to a Wifi approach:

recent generation audio HATs are better protected against EMI,RFI and noise
gadgets like isolator HATs are trying hard to eliminate the impact of EMI, RFI and noise as much as possible
Most recent USB DACs exhibit quite impressive noise suppression qualities

Bottom line.

I guess you'd agree, there are plenty of reasons to give WiFi a try.

Let's get some stuff done...

In this article you'll get information and How-To's in following areas:

Wifi network setup
Streaming network background information
Network quality questions
Logitechmediaserver network principle
Network performance measurements
System tuning opportunities generated by going Wifi (Annex) - Don't miss it!
Short tuning summary (Annex) - Don't miss it!

I hope all this will be useful to bring your own RPI properly OnAir too.

WiFi Network Setup

That's an easy one. Within 10 minutes I had it all up'n running on piCorePlayer!

As prerequisites you'll need

pCP installed on SD-card
a wired LAN connection to your router
(optional) you could also configure Wifi right away without LAN - but that's not that simple.
all your networking data - network name and password at hand and country code

Once hooked up to the wired network and powered up, you - as usual - access the RPI via WEB browser.

Then you configure the Wifi setup inside the pCP "WiFi Settings" section.

You enter your network name (ssid), password (psk), country code and security mode.

Based on the given country code the regulatory required transmit power levels and channels will be assigned! Make sure you select the right country code.

You also need to choose the security mode. Usually it's WPA-PSK. This setting needs to match your WAPs (wireless access point = router/repeater/bridge) configuration!
pCP offers a rather slim set of options, that might be a bit confusing. You might also find terms like WPA2, TKIP, CCMP asf. Simply try WPA-PSK.

Note: Don't forget - as seen above - to turn "RPi built-in Bluetooth" "Off"

Option: Wifi config without ethernet access

I'd like to mention another way to get WiFi enabled. This is a bit tricky for some people. This time it's done without using a wired LAN connection and without web-browser for the initial setup.

What if you don't have access to your router or you don't have a ethernet cable at hand?

There's a solution! It needs a bit of hacking though. It's described in the pCP manual. Just try the first part "Add wpa_supplicant.conf to boot partition on PC" .
You'd have to access and edit a text-based configuration file called "wpa_supplicant.conf", which can be found on the boot partition on the pCP image.
Then you'd have to edit the key Wifi parameters - ssid, psk, and country and save it.

At every boot pCP will look for this config file and if pCP finds it an automatic Wifi configuration process gets initiated. Once that's done pCP saves the config file under a different name (used_wpa_supplicant.conf) to avoid another initialization on the next reboot.
If you want to apply changes later on, simply move the "used_wpa..." file back to wpa_supplicant.conf, do your edits and reboot.

That'll be it on that part. Once your settings are saved and the PI is rebooted you should get connected to your Wifi network.

I did figure out 2 minor pCP issues during the setup process:

Wifi power management can't be turned off in pCP (usually turning power management off makes Wifi operation slightly more stable)
The ethernet services and port can't be turned off. WiFi and Ethernet services are both running side by side on pCP.

OK. Nothing we couldn't resolve by a small modification (see Annex).
I communicated these 2 minor issues to Paul@pCP. Would be nice to see these quite useful and very simple features being implemented in the future.

Wifi Environment

Let's have a look at the networking in a real world Wifi environment. That's one of the key challenges of this project.

Most important for an audio streaming environment will be its network performance.

Wifi is and will never be as good as a wired network connection. That's no secret. By using Wifi we can expect quite a drop on the network stability and bandwidth compared to a cable connection - you simply can't avoid it. And the rather weak RPI Antennas make live no easier.

If we still intend to go the Wifi route - we do - our goal got to be getting the best possible Wifi connection in place - minimizing the negative Wifi related side-effects.

To end up with a solid base for running a high performance (audio-streaming) Wifi network
I wrote up a little checklist. The more you're able to comply the better the overall result will potentially get.

The base ingredients:

Using state-of-the-art networking routers, repeaters or access-points
There's been a lot of development in recent years!
Good Wifi transmission and reception is key - avoid putting routers or repeaters in cabinets, behind walls, closed doors, hidden in corners or close to the ground.
On the other side avoid RPIs in metal cases, cabinets asf.
Keep the distance WAP->RPI as short as possible. (WAP->Wireless Access Point)
If you can't swap out your aged router, turn off Wifi on that router and replace it with a state-of-the-art repeater/bridge/WAP. (That's what I did)
"Wireless" repeaters should to be used as bridge. Run a cable to the repeater and Wifi then starts at the repeater, which then is running in Wifi bridge-mode.
Access the 5GHz band only - make sure no other Wifi client connects to it
keep in mind that the 5GHz range is much smaller and much more sensitive then
the 2.4GHz band. No walls, short distances etc. becomes even more important.
All "mesh" networking features should be disabled on the router, as well as
automatic band switching features. Some routers/devices switch clients from 2,4->5GHz and you wouldn't even notice.
You might turn off automatic channel assignment # which is not always that reliable - inside the router and choose manually a channel that's not that much occupied by others (most routers have a network statistics tool integrated).
Make sure the firmware is up2date on all of your network equipment and verify if your custom settings were kept after you ran a firmware upgrade.
Use high quality Ethernet cables for the wired connections
Optional: Some people even replace the power supplies of their network gear to increase stability.

In the end this list reflects somewhat what every sysadmin pro would need to consider for building a quality (Wifi-) network.

Keep in mind. Not only your audio streaming setup will benefit. Basically all Wifi clients will benefit from a well shaped (Wifi-) network.

LMS Networking

Next I'd like to give a quick introduction of how the LogitechMediaServer (LMS) networking works. That might help a bit to understand what we're doing later on.

The LMS uses a particular way of communicating with its clients.

During operation the LMS and its clients are using a mix of TCP/IP and UDP/IP network protocol stacks.
The LMS network implementation is called "Slimproto" (The original LMS was build by a company called slimdevices ->slimserver->slimproto - I hope that explains the term).

"Slimproto" is one of the key building blocks of the LMS universe.

Ah. Ok. One step back.

What's actually IP, TCP or UDP?

TCP and UDP belong to the IP (Internet Protocol) family.

TCP (Transmission Control Protocol)
UDP (User Datagram Protocol)

Pretty much all networks and the WWW make use of these protocols.

The TCP protocol is used for connection based links - segment streams - you might want to compare it to a telephone call connection with its continuous data flow.
UDP is used for sending one-off so called datagrams from a to b - you might compare it to a messenger service like e.g. WhatsApp.

TCP is the much safer protocol variant! The side-effect: TCP comes with quite some overhead. It's net use-data transfer can be around 20-30% lower then UDP.
The huge advantages of TCP over UDP: On a reasonably quality connection no data get lost. If packages are not received properly they will simply be resend. The package order can change and usually changes on a TCP/IP network. All data-packages are reorganized on the receiving end to get them back into the right order.
On a very bad connection though there is a risk of data loss - even on TCP/IP. That happens at a point where the disorder of packages is that big that e.g. buffers run out of space which would reorganizing the received data properly simply no longer possible.

UDP has no protection against data or package loss. And it will loose packages rather quickly, especially if you go the Wifi route.
The huge advantages using UDP: UDP is highly efficient, very fast and responsive.

LMS makes use of both protocols. Using TCP and UDP in a combined fashion is a smart way to utilize the strength and qualities that come with each of the protocols.
The LMS approach separates two complete different services, the audio data transfer (stream) and the control commands.
slimproto runs the audio-data over TCP and the control-data over UDP.
How it works. LMS basically connects to the client via TCP first to setup the connection. By the time the connection is established, UDP will be used to exchange control commands and status data. Using UDP for the control commands makes the setup very responsive. If a command fails, due to a loss of packages, you as a user just try again.
TCP will be used to transfer the actual audio data stream. TCP is used because you simply can't risk to loose or mixup the audio data.

I hope it's a bit more clear now how the LMS networking works in your streaming environment.

Network Quality

It requires a decent network quality to enjoy decent network services such as audio streaming. Especially if you stream over Wifi.

How do you know, how good your network is performing?

My rough guess: 99% of the people out there is not aware of what's going on inside their networks. Just lifting a wet finger in the air won't tell you anything about the actual quality of your installation.

That's why we need to measure it!

Consider a network performance test a mandatory part of the Wifi installation process!
If the Wifi performance turns out to be rather poor, it can you drive you nuts. All kind of weird things can happen - clicks, dropouts, connection loss, huge latencies on controls asf. asf. .

You don't want to be part of such a nightmare.

The great thing. There are SW tools available to measure your network quality. More on that later.

There are 4 network parameters I'd recommend to look at.

Signal strength
Bandwidth
Jitter (package jitter!)
Lost packages

The first you do is to figure out the signal strength. You need to run a single command:

sudo iw dev wlan0 link

You'll get something like this:

_____________________________________

Connected to f1:b4:14:41:df:df (on wlan0)

SSID: net11

freq: 5260

RX: 732119 bytes (4458 packets)

TX: 500365 bytes (2818 packets)

signal: -61 dBm

rx bitrate: 150.0 MBit/s

tx bitrate: 135.0 MBit/s

bss flags: short-slot-time

dtim period: 1

beacon int: 100

_______________________________________

As you can see the signal level on my established link is a pretty good -61dBm.

Let's talk a bit about reference levels.

Up to -67dBm values are considered very good.

@ -70dBm it's still OOOK. This boundary is considered the minimum signal strength for reliable packet delivery. Better stay higher than -67dBm.

@ -80dBm you might still get a connection, but such a link is pretty unusable.

If you can't achieve levels better than -67dBM at this point, I'd say skip the rest of testing for now. Try to rearrange/reposition your devices first. And then retest the signal strength before running the next test phase.

Let's have a look at the actual data flow. Even if the signal strength is OK. The data flow might look a bit different.

We'll have a look at the UDP network performance. Because to get UDP properly working is more challenging then TCP. And if UDP performs rather well, TCP works for sure. We can therefore skip TCP tests.

To give you a Wifi networking performance reference beside the earlier shown signal strength:

The best case scenario for a UDP connection on a 5GHz network using a RPI 3B+ or RPI 4 would be around:

Bandwidth : 137Mbit/s max
Package Jitter : 0.1ms
Package Loss : 0

Note: Jitter means - Latency variations between network packages - the lower the jitter
the more stable is the connection. ( The audio related jitter is something
completely different! )

How did I get these values? Performance testing!

Performance Test Setup

The big Q. How do we run the network performance tests?

It's actually rather simple. If you know how.

There's a great and very effective opensource network performance tool called iperf3.

iperf3 needs to be installed on a server and on a client. You start one instance
on the server in server-mode. On the client you start the 2nd instance in client-mode.
You need to inform the client where to find the server. That you'll do by giving the iperf instance on the client the server IP address at program launch.

iperf3 is available for all platforms - Windows, Linux and OSX. There are plenty of instructions out there how to install it on your preferred server platform. The packages you need to download and install on your server you'll find over here.
For some platforms (e.g. Windows) you'll also find "jperf", which is iperf3 with GUI.

In case you run a NAS as LMS server and therefore you'd run in trouble to install iperf3, you could also use any other "wired" PC in the network to act as iperf3 server for the network performance test. That'll be still better then not running the tests at all!

Usually iperf3 is also available on your RPI client. Basically all RPI operating systems have the tool in the repositories.

On pCP you simply install it as extension from the pCP repository (to be done via web browser). (It's now available.)

On pCP we (still) have to execute iperf3 from command-line. You should know the pCP ssh access procedure by now. (From pCP5.0 onwards the network performance test can be executed from the web-browser!)

I hope you'll manage to get the iperf3 installation done on both ends.

Performance Testing

Done with the iperf3 installation??? Great.

Now. How do we run the tests?

First you start iperf3 (commandline) or jperf (GUI) on your server.
Then on the pCP client (commandline).

On the server
(connected over wired Gbit LAN!)

iperf3 -s -V

"-s" = server mode
"-V" = higher verbosity

Jperf offers the same options inside the GUI.

Hint: Under OSX and Linux, by typing "ifconfig" before starting iperf3 in a terminal, you can lookup your servers IP address . You'll need that server IP address at hand to start iperf3 on your client!

With "CTRL-C" you can stop iperf3 at any time btw!

On the RPI client
(login via ssh):

iperf3 -c 192.xxx.xxx.xx -V -i 1 -A 1 -u -b 0 -t 60

"-c IP " = client mode + server IP address
"-V" = higher verbosity
"-i 1" = run 1 second intervals
"-A 1" = use affinity 1 = 2nd processor

"-u" = run the UDP protocol

"-b 0" = run maximum bandwitdh
"-t 60" = run a 60s test

(Enter the IP address of your own server in above command)

What are we doing here.

We run a 60s UDP performance test at maximum bandwidth in 1 second intervals.

Advise:
I'd suggest to stop squeezelite and the webserver on pCP before running the test.
Just copy/paste below line into the pCP terminal before your start iperf3.

sudo pkill -f squeezelite ; sudo pkill -f httpd ;

Once iperf is finished after 60s, you'll see what's going on. Copy/paste the iperf output to keep that info for your records.

After the tests you should reboot the RPI.

Performance Test Results - lab environment

I'll now show you test results of two tests I've been running.
Below you'll see the iperf3 output.

Testcase 1

180 degree - "Line of sight", basically the antenna is pointing away from the router
3ft distance

Bandwidth: 137MBit/s
Package Jitter: 0.139ms
Package loss: 0

That looks awesome.

Testcase 2

0 degree - "Line of sight", basically the antenna is pointing directly to the router
3ft distance

The result looks similar to Testcase 1, performing a little bit better on the packet jitter part.

Great. TC1 and TC2 results look consistent. That's reference performance under lab conditions.

Performance Test Results - real-world testing

I did some more testing later in the house on my main audio system.
I made sure the environment was well prepared. You've read the recipe at the beginning of the article!

The distance between RPI and my wireless bridge (AVM1750E) was about 6.5ft/2m with a few obstacles in line-of-sight and the antenna turned away by 180°.

I ended up with below results.

Not too bad. Still there should be some space for improvement on the throughput.

In general the 3B+/4 Wifi connection turns out to have much better throughput then all earlier RPI generations. The connection looks very stable. On the 3B even the wired Ethernet can't do better! The RPI 4 offers wired GBit Lan speeds. That's a different league. I use it for my RPI4 server.

Keep in mind though.

Above results do not reflect your own environment. The Wifi performance can degrade very quickly in a real-world and less optimal Wifi environment!

If I had one wish free,

I'd personally would prefer an external antenna attached to a U.FL socket. Because you

would be more flexible in placing the RPI and the antenna
would be able to use metal cases or other shields around the RPI
you could achieve much higher send and receive levels

I don't want to complain though. I'm more than happy with the current performance.

(However. I did look for hacks to attach an external antenna. There are none.)

Final Advise

I strongly recommend to run the network performance test!

Re-run these performance tests as soon as changes have been introduced to your devices, network or environment.

You should also consider to run the performance tests at Wifi traffic peak hours (e.g. early evening on weekdays).

You can take my above results as reference! If your results look "much worse" something should be improved in your setup. You've seen the checklist earlier.

OK. What would "much worse" mean??

Some rough indications:

Bitrate shouldn't be lower then e.g. 100MBit/s.
Package Jitter shouldn't be higher then e.g. 1ms.
Lost packages/datagrams shouldn't be much higher than about 10.

Of course the Wifi network will work with numbers below that. BUT.
There'll be higher loads and latencies on the PI. There can be slowdowns. There can be dropouts. There can even be lockups. Simply weird and random things can and you don't want to happen.

I'd like to mention one more aspect that underlines the need for a network performance test. The worse the Wifi networking environment, the higher the output power of the Wifi chips. Any Wifi chip in the network!

Meaning. Also your smartphone or tablet right in front of you might develop microwave oven qualities!

Bottom line. Just do the performance test exercise. Your Wifi performance will be no longer a black hole to you.

Conclusion

I don't see major showstoppers why the RPi 3B+ or RPI 4 OnBoard Wifi shouldn't be used for audio streaming purposes, assuming a stable Wifi environment.

the achieved network performance comes quite close to the ethernet performance of a 3B. Close enough to not cause any obvious downsides on the audio streaming part
fast and stable enough to cope with audio streaming challenges
beside that you can get rid of a lot of networking gear
and you set it up in no time and can easily move it from a to b.

However. I for myself are currently running my RPi4 server and RPi4 clients "wired".

Because

I had a well established wired ethernet infrastructure in place
wired is and always will be more stable
wired allows for GBIT Lan speeds, which really speeds things when bulk loading files
my audio chain noise floor and sensitivity is pretty low and well under control
USB can't be turned off on the PI4 and I'm using a USB DAC nowadays anyhow
and I can reduce EMI/RFI right at the audio device/streamer

Bottom line. I'd go wired, if it's possible, otherwise I'd try to setup a solid Wifi network.

Enjoy.

soundcheck's - audio@vise

the audio streaming series

the net