WF Server running on Pi zero W platform

For interested parties, I’m currently testing a Pi Zero W (not Pi Zero 2) running WF Server connected to an Icom IC-7300. Here are the steps I took to get a working WF server.

  • First I downloaded and imaged an SD card with PI OS (Debian) 32 bit. ** Must be the 32 bit image for Pi zero W.

  • I configured userconf with user name pi and wpa_supplicant.conf for a wifi connection.

  • I installed the build requirements as per: · master · Elliott Liggett / wfview · GitLab

  • I complied WF Server as per: Headless Server | wfview

  • Don’t forget # sudo make install.

  • Connected the IC-7300 via USB and set volume to 50% output in alsamixer… 50% on the radio side (input).

  • Started # wfserver with default config which sets a configuration file ~/.config/wfview/wfserver.conf

  • Change user and password in ~/.config/wfview/wfserver.conf

  • Create a system service:

.# sudo nano /etc/systemd/system/wfserver.service

.# /etc/systemd/system/wfserver.service
Description=WF Server



  • Start and enable service

    .# systemctl start wfserver
    .# systemctl enable wfserver

Cheers and 73’s, Mick VK3ADD


This is so cool, thank you for posting!

How is the CPU usage?

de W6EL

see Add background mode to wfserver (#96) · Issues · Elliott Liggett / wfview · GitLab

thanks Mick. Will refer you when we add it to the source

1 Like

G’day Elliott,

It’s almost usable but with the lack of CPU overhead, I see some audio lost and in some cases the wfserver falls over.

Unless CPU usage can be lowed, it maybe a no go.

Single core and 512 MB RAM, correct?

Are you using wifi for the connection?


de W6EL

Hi Mick

There is still quite a bit of the command handling code in wfserver, which is not needed so I may be able to reduce the CPU consumption a small amount. This is on my list to look at.

The vast majority of CPU is taken with audio encoding/resampling so one option is to set the native sample rate of Linux audio to 48K and use 16bit 48K on your client. This should passthrough the audio “practically” untouched. You should see from the server log what the current native sample rate/format is.

Are you using Opus audio? This can sometimes result in lower CPU as it sends much smaller packets.

73 Phil M0VSE

Maybe a little less audio dropped using Ethernet and not WiFi.

Yes it’s the pi zero with a single core and 512MB of RAM.

Hi Mick.

A more useful view is top -H which will show all threads. Most wfview/wfserver threads are named to make identification easier:

ps ax | grep wfserver
top -H -p <pid of wfserver>

73 Phil M0VSE

Thanks guys for the input, it is appreciated :slightly_smiling_face:

Systemd maybe making trouble here. I see less CPU usage outside of systemd!!

I’m seeing higher CPU usage using Opus over LPCM16.

I guess it’s all about finding balance between network bandwidth and CPU. Opus is complex and does a lot of computational things to lower the network bandwidth requirements. PCM, on the other hand, is pretty raw. Lots of bandwidth but no processing.

uLaw may be a good option since it uses a lookup table to get considerably more than 8 but dynamic range out of an 8 bit stream. Very low CPU with it.

1 Like