Ubuntu Server 18.04 on Raspberry Pi 3B+

[CharlieLaub]

I use Gstreamer as my DSP processing platform under Linux. Raspbian has been lagging badly behind in terms of keeping software in the OS current. Under Raspbian Gstreamer is version 1.10x while 1.14x is the most current stable version and has been out for months.

I recently picked up the latest Raspberry Pi hardware, the 3B+, so I thought I would see if I could install a more mainstream linux distro. I usually use the Pi headless (no monitor) so I don't need a GUI or desktop, etc. I discovered that the latest LTS release of Ubuntu, 18.04, is available in a "server" version that is headless and comes as a precompiled image for the Pi 3. This means, just like Raspbian, you can download it, put it on a SIM card, and you are up and running in minutes. Wow, that is great, and now I have Gstreamer 1.14.1 at my disposal. I thought I would share this news here, since I know some of you may be interested.

You can get Ubuntu Server 18.04 for the Pi 2 and 3 here:
Ubuntu-18.04.2 LTS (Bionic Beaver)
It's listed under the section called "Preinstalled server image" near the top of the page.


You will need to unzip the xz file first. I used WinZip on my Windows machine. Then I used a disk imager (Win32DiskImager) to load it on a 16GB class 10 sim card via a USB-->SimCard adapter.

For the first boot, username and password are both "ubuntu" and you should be prompted to change the password. This is an administrator account, and sudo-ing does not require you to re-enter the password. Connect the Pi via an ethernet cable and so some updating. You should run

sudo apt update
sudo apt upgrade

Remember, this is a command line only server version of Ubuntu. It doesn't even include ALSA at boot up, so you need to install that if you want to do anything audio related. Try:

sudo apt install alsa alsa-tools alsa-utils

I'm currently using a USB ADAT adapter plus an ADAT AD/DA unit to simultaneously run 8channels of 24bit audio at 48kHz in and out of the Pi using Gstreamer. HTOP shows that the Gstreamer CPU utilization is only about 1-2% for each of 4 threads. I can add on top of this LADSPA processing and implement a multi-way DSP crossover with plenty of CPU horsepower to spare.

 

[Davey]

Very good. Thank you.

Dave.

 

[CharlieLaub]

Still poking around the install...

The GPIO pins seem to be accessible using the techniques described on this web page:
https://www.kernel.org/doc/Documentation/gpio/sysfs.txt

I was able to export and unexport a pin, but have not tried it e.g. by toggling an LED, etc. I had to do it as root. I encountered the same issue during a previous project on a Linux machine as reported HERE that:

There was one problem: I needed to be superuser to toggle the GPIO pins. I realized that all the newly available GPIOs were owned by user "root". So I changed user to become root (via sudo su) and then changed the owner of each GPIO folder and the files within them to be owned by my regular user account. This eliminated the need to use sudo when toggling the value or changing the in/out pin mode.

It's likely just a matter of changing the ownership from root to my user account. I will try this. In any case, this is one way to access GPIO pins under Ubuntu.

I will report any other glitches or problems that I discover.

 

[CharlieLaub]

Here is some info on how to get wireless networking up and running under Ubuntu Server:

Install wpasupplicant:

sudo apt install wpasupplicant

Edit the netplan:
Find a file within the directory /etc/netplan with the extension "yaml". On my system this was called 50-cloud-init.yaml and contained the following text (prior to my edits):

# This file is generated from information provided by
# the datasource.  Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    version: 2
    ethernets:
        eth0:
            optional: true
            dhcp4: true
            match:
                macaddress: 00:11:22:33:44:55
            set-name: eth0

The mac address will be the actual address of your board's ethernet interface.

I added the following section for WiFi:

    wifis:
        wlan0:
            optional: true
            dhcp4: true
            access-points:
                "my-network-name":
                    password: "network-password-as-plain-text"

YAML files follow strict indentation rules as part of the file structure. Make sure to indent lines as shown. Substitute your network name, and its password as plain text. Keep the double quotes around each.

Restart Networking:
Save the file and then run the command:

sudo netplan apply
sudo service network-manager restart

Your board should now connect via either/or/both WiFi and/or ethernet, as they are available.

Also, networking info that used to be obtained with ifconfig and other commands is now obtained using the ip command. Info here:
Linux ip Command Examples - nixCraft
ip(8) - Linux man page

For example:

ip a

shows the status and info for all interfaces

 

[CharlieLaub]

Wow, things are moving fast! The web page I linked to for Ubuntu 18.04.1 server beta has already been taken down. You can now download precompiled Ubuntu server 18.04.2 images for the Rapsberry Pi here:
Ubuntu 18.04.2 LTS (Bionic Beaver)
It's listed under the section called "Preinstalled server image" near the top of the page. I checked and the beta version I started with has been updated to 18.04.2 via apt update/upgrade. I modified the opening post with this new download location.

So far the only glitch I found so far is that alsamixer only works if you call it with a card specified, like this:

alsamixer -c 1

Calling alsamixer without the -c argument causes it to return with "mixer not found".

 

[phofman]

So far the only glitch I found so far is that alsamixer only works if you call it with a card specified, like this:

alsamixer -c 1

Calling alsamixer without the -c argument causes it to return with "mixer not found".

Default alsa device is the pulse plugin which offers no controls of type MIXER.

 

[soundcheck]

What kernel is Ubuntu-Arm using?

I suppose Mainline + Ubuntu flavor.

That'd be an absolute NoGo (for the time being).


I'd say with all the patches and features Raspbian and ALARM are still
the OSes of choice for the Pi family.


Enjoy.

 

[CharlieLaub]

What kernel is Ubuntu-Arm using?

Welcome to Ubuntu 18.04.2 LTS (GNU/Linux 4.15.0-1031-raspi2 aarch64)

 

[soundcheck]

The main issue with such a mainline kernel is the lack of the very specific RPI kernel device tree and patches.

Basically most of the nice HAT (audio) devices wouldn't work on a mainline kernel.
And it's that RPI kernel device tree what makes a RPI interesting in the first place.

And even as a SBC for USB audio devices a RPI would simply be the wrong choice.
There are much better suited SBCs out there.

Beside that there are several other device tree related parameters that can't be used anymore.

It's IMO just a fun project - Ubuntu-On-Pi.
I've been playing around with Manjaro (also comes with a 64bit mainline kernel) for a while - for a different purpose.
Working with it is awful!! Simply starting Firefox is a nightmare. You'll face dead-ends&bottlenecks at every corner.


Enjoy. I don't. Waste of time projects - IMO.

 

[CharlieLaub]

The main issue with such a mainline kernel is the lack of the very specific RPI kernel device tree and patches.

Basically most of the nice HAT (audio) devices wouldn't work on a mainline kernel.
And it's that RPI kernel device tree what makes a RPI interesting in the first place.

And even as a SBC for USB audio devices a RPI would simply be the wrong choice.
There are much better suited SBCs out there.

Beside that there are several other device tree related parameters that can't be used anymore.

It's IMO just a fun project - Ubuntu-On-Pi.
I've been playing around with Manjaro (also comes with a 64bit mainline kernel) for a while - for a different purpose.
Working with it is awful!! Simply starting Firefox is a nightmare. You'll face dead-ends&bottlenecks at every corner.


Enjoy. I don't. Waste of time projects - IMO.

Thanks for pointing that out - that HATs will likely not work. I dunno, I don't use "HATs" I use USB audio only because I typically need more than 2 output channels and I also sometimes want audio input(s). This means I use either multiple USB stereo DACs or I use a multichannel USB pro audio interface.

About the only thing I use from the PIs pins are the GPIOs, so that I can for example trigger amps to turn on and off. This seems to be supported with the Ubuntu image.

Since I don't use the OS itself for playback I never use these canned audio-specific OSes like Volumio, etc. I only use the PI for DSP processing, and either stream audio to the unit over WiFi or I use the audio input from the USB soundcard. For DSP using IIR filters (via LADSPA) there is plenty of processing power on tap and the PI platform is cheap. I just have not liked how Raspbian has evolved lately, and was always hoping that mainline linux would be supported. I had tried Ubuntu+MATE images before but was not very satisfied, so the fact that there is now a current LTS Ubuntu image is perfect for my needs.

YMMV.

 

[soundcheck]

If it serves your "special" purpose, that's great.

The RPI is a special purpose animal by definition.


When it comes to serious DSP work, I do prefer my i5 NUC.
The Intel platform is just better suited for that purpose.

 

[CharlieLaub]

If it serves your "special" purpose, that's great.

The RPI is a special purpose animal by definition.


When it comes to serious DSP work, I do prefer my i5 NUC.
The Intel platform is just better suited for that purpose.

I hear you on that. I recently bought a fanless "mini PC" from Zotac that has been working very well under Ubuntu. It uses an Intel N4100 CPU - not as powerful as your i5 NUC, but the low TDP of the CPU allows it to run totally silent.

 

[soundcheck]

Just to avoid that people think I'm pushing out empty phrases regarding DSP.

Here's a benchmark I did offline upsampling a 44.1 flac file to 352k8 Hz
on both platforms.
The binaries and datafiles were located on a tmpfs-ramdisk. On both platforms the performance governor were active.

Both sox binaries were already CPU specific optimized manually compiled binaries.
Which means basic platform delivered precompiled sox binaries are usually performing worse.
Partly much worse!


i5 Broadwell NUC:

Binary = /tmp/sox-NUC-opt

real 0m14,821s
user 0m14,552s
sys 0m0,269s

RPi3 B+ :

Binary = /tmp/sox-ARM-opt

real 2m38.489s
user 2m36.702s
sys 0m1.428s

That's giving a rough ballpark - I hope.

 

[CharlieLaub]

Just to avoid that people think I'm pushing out empty phrases regarding DSP.

Here's a benchmark I did offline upsampling a 44.1 flac file to 352k8 Hz

Why in the world would you ever do that???

I have no need or desire for anything higher than 96kHz sampling rate, ever, period. I use 48kHz for all of my systems. "More" is not "better".

 

[phofman]

Well, it is about 10x difference. Interesting...

 

[CharlieLaub]

Well, it is about 10x difference. Interesting...

But not at all surprising, really. A Raspberry Pi, even the "latest and greatest" 3B+, is really NOT at all in the same league as any laptop or desktop CPU in terms of computing power.

On the other hand it does cost only $35, is well supported, has a small form factor, low power consumption, is fanless, can run mainstream linux, includes built-in wireless networking hardware (e.g. 3B+), and is perfectly adequate for real-time, multichannel DSP IIR filter processing. When used as a multichannel DSP crossover platform, it's great, when paired with the right soundcard.

It's certainly not going to replace a higher powered computer, ever, but it does have its application sweet spot that can certainly be considered "serious". It's not as limited as e.g an Arduino that is best suited to blink LEDs, run a robot, etc.

 

[soundcheck]

Why in the world would you ever do that???

I have no need or desire for anything higher than 96kHz sampling rate, ever, period. I use 48kHz for all of my systems. "More" is not "better".

OK. That's now a complete different subject. Don't say "...ever, period!" before understanding what's been talked about.

You're simply looking at it from the wrong angle.

Pretty much all DACs apply internally digital filters, do oversampling/resampling asf.
Usually they do it - in line with their HW limitations - at mediocre qualities.

Now.
352k8/384k I'm running on the TI PCM51xx DAC family. At these rates you'll bypass the internal filter structures of these DACs.

Basically the equation will be "Internal DAC filters" vs. "Externally resampled data"

The entire subject is purely related to DSP.

It would be the same from your angle to say "24bit - that's it. Period!" That would be as wrong in the DSP world. You work with 64bit floats to limit losses. Again. A complete different subject.

And it's not only that you bypass the internal mediocre filters. sox @ 64bit with all the tweaking options will pretty much always provide better DSP quality.


Each audio device/DAC looks different internally though. For some other DACs, like ESS Sabre, above wouldn't make any sense. You need to analyse
what your DAC is doing internally to find the potentially best solution for it.

 

[CharlieLaub]

OK. That's now a complete different subject. Don't say "...ever, period!" before understanding what's been talked about.

Well, OK, but I really do not find any benefits above 96k for my personal needs.

You're simply looking at it from the wrong angle.

Pretty much all DACs apply internally digital filters, do oversampling/resampling asf.
Usually they do it - in line with their HW limitations - at mediocre qualities.

Sure, DACs have an internal anti-aliasing filter. I was not aware that a DAC did any resampling internally... do they? Why do you think anti-aliasing filters are "mediocre" even on the cheapest DACs?

Now.
352k8/384k I'm running on the TI PCM51xx DAC family. At these rates you'll bypass the internal filter structures of these DACs.

Basically the equation will be "Internal DAC filters" vs. "Externally resampled data"

OK, that approach is something new to me and I see what you are doing now with the massive upsampling in order to bypass the DAC processing, or at least make it have no impact by pushing it way up above the audio band. Interesting. It is certainly a valid approach if you feel the resulting audio is better.

The entire subject is purely related to DSP.

It would be the same from your angle to say "24bit - that's it. Period!" That would be as wrong in the DSP world. You work with 64bit floats to limit losses. Again. A complete different subject.

And it's not only that you bypass the internal mediocre filters. sox @ 64bit with all the tweaking options will pretty much always provide better DSP quality.


Each audio device/DAC looks different internally though. For some other DACs, like ESS Sabre, above wouldn't make any sense. You need to analyse
what your DAC is doing internally to find the potentially best solution for it.

I do use inexpensive stereo Sabre DACs (e.g. with ES9023) but also pro audio recording interfaces with unknown hardware but known specs. I don't use Sox. I do everything using Gstreamer including streaming, routing, DSP processing via LADSPA, sample rate and bit depth conversion, and so on.

It seems our goals and interests are quite different. Some of these things are seemingly of strong interest for you but maybe not for me as much, and I have other needs that come first before most of these issues. That's not an attempt to take anything away from what you are doing or explain away my disregard for the issue you raised above.

Anyway, we are kind of drifting away from the thread topic now...

 

[daemonsgr]

Really cool info you have on your site!
Thnx

 

[soundcheck]

Well, OK, but I really do not find any benefits above 96k for my personal needs.

I simply told you that there are areas that benefit from running these high rates. You asked for it.

Sure, DACs have an internal anti-aliasing filter. I was not aware that a DAC did any resampling internally... do they? Why do you think anti-aliasing filters are "mediocre" even on the cheapest DACs?

DACs are more complex.

* External filters can get much better, much better tweaked. That's basically what all your LADSPA stuff is all about, isn't it.
* You'll find ASRCs inside DACs asf, asf.
* Did you follow the Soekris Filter Brewing thread. Just another example.

OK, that approach is something new to me and I see what you are doing now with the massive upsampling in order to bypass the DAC processing, or at least make it have no impact by pushing it way up above the audio band. Interesting. It is certainly a valid approach if you feel the resulting audio is better.

If you also run DSD/DOP these "massive" rates become standard anyhow.
Your chain simply needs to be able to cope with them.

Several ASRCs delivering 768kHz as FS-out btw.

Once more. These "massive" rates have pretty much nothing to do with the actual AD/DA process. That's your perspective. They do come with advantages on the processing/filter part. But. As shown in my benchmark, the processing power
for HQ resampling is quite high. That's why the HW based SRC is usually not of best quality.

I do use inexpensive stereo Sabre DACs (e.g. with ES9023) but also pro audio recording interfaces with unknown hardware but known specs.

I mentioned Sabre. I used to have one 9023 HAT too. My current setup I simply consider quite a step up.
I btw sold my Pro Audio RME device quite a while ago, because it sounded worse - then these tiny (tweaked) el-cheapos.

It seems our goals and interests are quite different. Some of these things are seemingly of strong interest for you but maybe not for me as much, and I have other needs that come first before most of these issues. That's not an attempt to take anything away from what you are doing or explain away my disregard for the issue you raised above.

Not necessarily. I've done active filtering/crossover/convolution with brutefir/ecasound/ladspa etc. years ago. We're just at different stages.

I did realize that running and tuning a multichannel chain (based on a non-DIY RME Fireface ) would hardly achieve the quality of a well tuned dual channel DIY-DAC setup.