Raspberry Pi + CirrusLogic Audio Card = FAIL

Anybody had luck building a decent music rendering system out of the Raspberry Pi plus a Wolfson / CirrusLogic Audio Card? My efforts have been a disappointing FAIL.

I'm trying to build a simple media rendering device out of a Raspberry Pi. I know, I know, it may not be the most HiFi solution to the rendering problem, but for this application I'd be content if I could get something up and running that works like a Squeezebox and has passable audio quality for non-critical applications.

The inherent audio system of the RPi (analog output) is well known to be just awful. My experiments were in line with everyone else's in that regard -- the result was lots of cracks, skips and pops. It was a total failure.

Things looked encouraging when Newark Electronics / Element14 in the USA started to co-market the CirrusLogic (formerly Wolfson) Audio Card. I'm in the US, and having a local distributor like Newark / Element14 seemed like it would solve some of the accessibility problems involved in ordering parts from the UK.

The CirrusLogic (Wolfson) card seemed like a decent option, but so far all of my efforts have resulted in failure. I'm wondering if anyone else has gotten the combination to work, and if so, how they've done it.

My first effort was to buy a new Raspberry Pi 2 (quadcore) device and a copy of the latest CirrusLogic Audio Card from Newark/Element14.

When I bought the CirrusLogic card, Element14 was marketing it as being compatible with the RPi 2, but they stopped advertising it as being RPi-2 compatible when it became evident that it was only pin-compatible as a plug-on card, and was not software compatible.

The problem, as discussed on the Element14 site, is that CirrusLogic still hasn't done their job of writing the ARM-7 compatible drivers for the quadcore RPi-2. At this point in time, the software support for the hardware on RPi-2 remains vaporware, which has resulted in quite a few disgruntled customers.

Community: Cirrus Logic Audio Card | element14

My second effort was to fall back to installing the CirrusLogic Audio Card on a Raspberry Pi B+.

Since the audio card wouldn't work with the ARM-7 quadcore RPi-2, I decided to use the ARM-6 RPi B+ as a fall-back option. Element14 is still advertising these products as being compatible. Unfortunately, my efforts to get the card up and running on the single-core RPi B+ haven't fared much better:

With the B+ I've found it impossible to build the kernel drivers, largely due to the fact that the manufacturer's wiki article is poorly written and contains enough errors to force the effort to result in a FAIL.

Has anybody had luck in getting the Wolfson or the CirrusLogic Audio Cards to work as a rendering device on the Raspberry Pi? I'm having a bear of a time getting the hardware/software to work, and I'd really like to know if anyone has been successful in doing it.

If you have been successful, please let me know whether you've been happy with the quality of the audio output and the usefulness of the device as a music renderer. I'm hoping to find out if it's possible to succeed in the task that I'm trying to accomplish, whether the functionality and sound quality are worth the additional time and effort that's going to be required to get it to work, or if I should just fall back and punt.

TIA.
 
Last edited:

DRONE7

Member
2008-08-21 11:12 am
I have not used the Wolfson but am very happy using a PiB and a HiFimediy i2s dac running Tcmods rewrite of Volumio/Rune.
tcmods.org
Hifimediy ES9023 I2S DAC for Raspberry Pi mod B 192Khz/24bit

You may be best to ask about the Wolfson on the Volumio forums.
https://volumio.org/forum/

https://volumio.org/
RuneAudio - Embedded Hi-Fi music player

Some other links for working versions using the Wolfson...
https://www.bostonenginerd.com/posts/getting-the-wolfson-audio-card-working-with-volumio/
http://www.runeaudio.com/forum/wolfson-audio-card-patch-for-runeaudio-t213.html

For info...
Volumio has good up to date hardware and kernel support but a UI that is slow and lacking features. Supports several platforms.
Runeaudio has a good UI but kernel support lags a little.Supports several platforms.
Tcmods has up to date kernel support, an excellent, fast, full featured, UI. Supports RPi only.
 
Last edited:
I can provide my experience, but...
there's always a BUT....

I use RasPi B (plain old "B", not "B plus"!).... and I use old Wolfson card, not the newer Cirrus Logic advertised as pin-compatible with B+ and RasPi 2 models...

So, FWIW, I can't contribute much to your particular situation, unless you replace both the RasPi and the Cirrus card you have for older models (both)...

Once you do that, you will have a working combo and a choice of audio distros you can use (RuneAudio, Volumio, Squeezeplug, etc...).

What can I say: Wolfson (and now Cirrus Logic) certainly made a mess of all this, and they did have a good product, which could have taken off fabulously, if only they provided proper drivers....

To cut the long story short, the only thing I found online which claims to work is this:
https://blog.georgmill.de/2015/02/18/update-for-wolfson-audio-card-on-raspberry-pi/

You could try that, as the last resort... (Disclaimer: haven't tried it, don't know if it will work...)

Next time, it would be wise to research the hardware and software combinations for potential problems prior to purchase....

Regards,

Denis
 

maestroji

Member
2015-03-10 1:30 pm
Hi Folks,
Like most of the other Computer Audio enthusiasts I too faced many problems at the start but being encouraged by my friend JDG I persevered to obtain a good Audio Card, an easy-to-setup media player, an efficient remote control device and high audio quality output through my Audio Research PreAmps, Audio Research Power Amp and Gallo Loudspeakers. And the Audio Card had to be as good or better than my Audio Research DAC.
After much trials with Audio Cards, Media Players and Remote Control Devices, I believe that I have achieved my objectives.
The upstream equipment is as follows :
Audio Card : RaspberryPi with Wolfson Audio Card
Media Player : OpenELEC 5.0 with the original OS replaced with HiasSoft's OS (www.horus.com/~hias/tmp/openelec-wolfson...-r19846-g3a9322c.tar)
Remote Control : Sybu with iPhone and iPad
The Wolfson Audio Card is extremely flexible and permits various inputs and outputs and high quality audio output.
The OpenELEC OS is also extremely flexible, permitting Audio, Video, Picture and Internet Downloads like YouTube, etc..
The Sybu Remote Control is very easy to setup and use with automatic detection of IP Sources and works seamlessly without monitor or TV or any Display Devices, except of course when viewing Videos and Pictures.
This easy-to-use upstream audio system owes its workability purely on the great work and advice provided by the Meister HiasSoft from Austria to whom I am deeply indebted and also to my friend JDG who is always full of encouragement and advice.
So there we have it folks my two cents worth of experience.
Thank you all for sharing this with you.
 
I have ripped all my CDs to FLAC format files and use a Squeezebox 3 to play them, from an old computer running the Logitech Media server software. I was looking for a second player to use in a different room and decided to try the Raspberry Pi + Wolfson Audio Card combo.
In May 2014 I purchased a Raspberry Pi Model B (MCM Part #: 83-15670) and the Wolfson Audio Card (MCM Part #: 83-15550). Using the OS downloaded from Element14's web site I was able to boot it up and play FLAC files, but I had to use the keyboard and mouse attached to the Raspberry Pi, as well as keep a monitor connected to it.
I decided to try Squeezeplug (SqueezePlug). I downloaded and installed it following the instructions provided in their web site. Using a tablet (not a fruity one!) I accessed the Logitech Media server web pages and saw the Squeezeplug player. I was able to play different songs, all of them flawlessly.
To see how well it performed, I downloaded sample hi resolution files from different sources. Even though the Raspberry Pi + Wolfson player is able to handle files up to 192KHz/24 bit, those play with random clicks. Files with resolution up to 96KHz/24 bit play perfectly. I connected the Raspberry Pi + Wolfson player to the DAC in my main system and played different files in the Squeezebox and the Raspberry Pi simultaneously, switching the input selector on the DAC. I could not hear any difference between the players.
For my use the Raspberry Pi + Wolfson combo, controlled using a tablet is perfectly fine. I hope this helps.
 
is Raspberry Pi 2 compatible with i2s dacs? if so, I'll buy one.

what software can I use? (I can't use linux at all, so can't change kernel, and so on.)

I can tell you with absolute certainty that the CirrusLogic / Wolfson Audio Cards are not compatible with the Raspberry Pi Model 2. Period.

Another problem is that the drivers that allegedly "work" with the RPi Model 1 (A, B, A+, B+) are defective and the OS has bugs. More on that later.

Here's what you need to know:

1. The CirrusLogic Audio Card (latest version) is Being Marketed by it's USA Distributor Newark / Element14 as being Raspberry Pi 2-compatible even though it is not.


If you go to the Newark/Element14 site, there are plenty of threads where people are complaining that the product just doesn't work:

Community: Cirrus Logic Audio Card | element14

Here is an image capture off of the Newark / Element14 web site that advertises the card as being Rpi2 compatible. It's just not true:

[IMGDEAD]http://www.element14.com/community/servlet/JiveServlet/showImage/105-53618-218090/2015-03-12_183519.png[/IMGDEAD]

Sure, the card is physically compatible with the pin headers on the RPi2, so it's hardware-hardware compatible. But the truth of the matter is that the software that's required to make things work is nothing but vaporware.

The problem is that the new quadcore RPi2 is an ARM-7 device and Cirrus Logic has not provided any ARM-7 compatible drivers. The only drivers that they have provided are ARM-6 drivers for the original RPi (Model 1). Today, you have no chance in hell of getting the Wolfson-type cards to work with an RPi-2.

2. The Wolfson-derived cards don't even work well with an RPi-1:


First, CirrusLogic doesn't distribute the kernel and the driver package needed to operate the card as a .deb or as an .rpm file. This means that it's not possible to directly update your existing linux installation to use the card. You have to either compile your own kernel/driver, or you have to wipe-out your existing installation and install and image of a special CirrusLogic linux distribution that contains their kernel and driver.

Second, CirrusLogic expects you to compile your own kernel and drivers. Doing this is fraught with peril, as Cirrus' instructions for how to do this are defective. If you follow their tutorial on how to compile a kernel, and you follow it to the letter, you're guaranteed to fail because the instructions are not written correctly. The instructions contain all sorts of path errors that the user will have to know enough to correct on his own. Otherwise the make will fail.

Third, CirrusLogic doesn't provide any instructions for how to recompile the kernel and drivers within the native Rpi environment. This is the safest/most compatible way to perform the make, and it could be done overnight. Unfortunately, Cirrus' instructions force you to attempt cross-compiling on an external linux box, and they make no consideration for the problems that people are running into when trying to compile 32-bit code on modern 64-bit systems.

Unfortunately, your best option (the only way I was able to get any sort of functionality on my B+) is to completely wipe-out your existing linux installation, and install the CirrusLogic version of Raspbian. The problem is that there are so many bugs in the system that it's just not useable as an embedded music rendering device.

Fourth, CirrusLogic's version of Raspbian is incompatible with any of the official Raspbian kernels. For example, if you install the CirrusLogic version of Raspbian, and you try to perform a system update, you will irreversibly break the kernel/driver that are required to run the audio card. This means that if you build a system using the Cirrus version of Raspbian, you're left with an OS that you can never update without breaking it. What a PoS.

Fifth, CirrusLogic's version of Raspbian is buggy. You can install it right out of the box, and it works. But if you attempt to do something smart -- like perform any of the accepted configuration changes in /etc/fstab to prevent the SD card from being constantly written to, which ruins the SD card -- the Cirrus version of Raspbian will break.

As an example, I changed the contents of /etc/fstab to place the commonly written-to files in a temporary file system, so that repeated writing to the SD card will not wear it out and require it's frequent replacement. It's something that everyone who uses an RPi as an embedded device has to learn to do, in order to avoid the PITB of contstantly having to replace corrupted SD cards. The typical modificaiton is as follows:

Code:
proc            /proc     proc    defaults 0 0
/dev/mmcblk0p1  /boot     vfat    ro       0 0
/dev/mmcblk0p2  /         ext4    ro       0 0
/dev/mmcblk0p3  /home     ext4    defaults,errors=remount-ro  0  1
none            /var/run  ramfs   size=1M  0 0
none            /var/log  ramfs   size=1M  0 0


Unfortunately, implementing the line that reassigns /var/run to a ramdisk reveals a problem with a kernel/driver bug in the Cirrus distribution. Although this fstab file is 100% compatible with the official Raspbian distribution and the unofficial Pidora/Fedora distribution, when it is used with the CirrusLogic distribution line #4 causes the kernel to stop recognizing the KB and mouse at boot. This appears to be a bug that is specific to the custom-kernel provided by CirrusLogic. (there have been many reports of bugs in the CirrusLogic kernel modifications, which is supposedly why Cirrus can't introduce an ARM-7 kernel into the linux kernel branch.)

What good is an OS that breaks the computer's ability to recognize your keyboard and mouse?

In my case, I'm using nothing out of the ordinary. I'm using a Microsoft keyboard and a logitech mouse, and neither will be recognized at boot-up by the CirrusLogic version of linux, even though these peripherals were working fine with both Raspbian and Pidora. To get the KB and mouse to work I have to continuously unplug and replug them to force re-recognition. What a PITB.

All things considered, the CirrusLogic Audio Card is a horrible PoS that I wish I'd never bought.

Hearing people say that I screwed up by not doing due diligence is not at all helpful. Before making my purchase I did perform due diligence -- I contacted the USA distributor (Newark/Element14) who told me that all of the kernel/driver problems had been solved, and that the product was compatible. All I had to do was to install the official CirrusLogic version of Raspbian. It turns out that the CirrusLogic version of Raspbian is a PoS that is buggy, and the product that they were selling has lots of problems with the RPi-1 and will not work at all with the RPi-2.

I wish I'd never bought it. If you're thinking about it, my advice would be to avoid it.

I have 15 years experience with Linux.
 
Last edited:
In May 2014 I purchased a Raspberry Pi Model B (MCM Part #: 83-15670) and the Wolfson Audio Card (MCM Part #: 83-15550). Using the OS downloaded from Element14's web site I was able to boot it up and play FLAC files, but I had to use the keyboard and mouse attached to the Raspberry Pi, as well as keep a monitor connected to it.

Just thought I'd ask -- what, if anything, have you been doing to avoid the problem with the RPi corrupting it's SD cards?

To get the RPi to truly function as an embedded-type music rendering device (ie: no keyboard, mouse or display), it'll be necessary to re-configure it so that it's not functioning like a desktop computer, which expects a KB/mouse/monitor to always be connected, as well as a hard disk to be connected for writing of the system logs.

One of the first steps required to reconfigure the Pi as an embedded rendering device is to stop logging to the SD card, which is notorious for corrupting the SD media -- especially if the device ever loses power. I've had to replace corrupted SD cards several times on my RPi that is left running, and at $15 a pop for SD cards, I've ended up spending more on replacement SD cards than I've spent on either the RPi itself or the Wolfson-type audio card.

As I mentioned earlier, when I used the universally accepted /etc/fstab entries to stop logging to the SD card, the CirrusLogic distribution responded by refusing to recognize my USB KB/mouse at boot. It looks like their kernel has a bug in which USB device polling/recognition fails at boot if /var/run is mapped to a ramdisk.*

Even though the Raspberry Pi + Wolfson player is able to handle files up to 192KHz/24 bit, those play with random clicks. Files with resolution up to 96KHz/24 bit play perfectly.

Well THAT is bad news. Essentially, you've added a Sixth reason to my list of reasons why the Wolfson-type cards SUCK on the RPi Model 1 boards.

The whole appeal of the I2C add-on cards is to avoid the crappy clicks and pops that come with the native RPi analog audio system. If the card isn't capable of playing 192/24 without clicks and pops, then you've given me the answer that I need to know -- there is no point in putting any further effort into getting this PoS to work, because in the end it's not going to provide satisfactory results.

Would I be correct in understanding that when you experienced clicks and pops at 192/24 that you were streaming audio across a LAN, from your audio server, into the 10/100 ethernet port on the Pi, and rendering through the Wolfson card?

If that's the case, then the RPI B or B+ solutions have no chance of any outcome other than a resounding FAIL.

Our only hope is that the multicore Model 2 B could do the rendering without clicking and popping ... that is, if Cirrus ever provides a kernel that will recognize the card on the ARM-7 platform.

I'm not holding my breath.


* Reviewing dmesg and /var/logmessages, the cirrus kernel is reporting that both the KB and mouse are recognized by the kernel. No errors are issued, but the KB and mouse still don't work. When hotplugging them, the logs show that the devices are disconnected and reconnected. The kernel logs the exact same device recognition information as it did previously. Even though the logs show the same information both at boot and after hotplug, the devices only work after hotplugging. What a PITA.
 
Last edited:
It is common knowledge that Cirrus' kernel patch itself is what is defective, and that Cirrus cannot get their driver included into the mainline linux kernel because it is not compatible. Their shoddy patch breaks other things. Like KB and mouse recognition.

Volumio and Rune both use the Cirrus kernel patch. Should I expect the outcome to be different?
 
Just thought I'd ask -- what, if anything, have you been doing to avoid the problem with the RPi corrupting it's SD cards?

I have not had that problem. The Squeezeplug is a complete solution and its version of the OS is optimized to host a headless player. Over the past several months since I assembled the media player, I have cycled it on and off over 100 times with no problems. However, I have never just shut down the player by cutting the power to it. I installed PuTTY on the machine hosting the Logitech Media server and, before shutting it down, I remote into the player and shut it down (shutdown -hP). The player does not currently have a keyboard, mouse or monitor connected to it.

In my previous post I included the part numbers for the RPi board and sound card. Please visit MCM Electronics: Home and Pro Audio/Video, Security and Test Equipment and verify if we are talking about the same devices.

Would I be correct in understanding that when you experienced clicks and pops at 192/24 that you were streaming audio across a LAN, from your audio server, into the 10/100 ethernet port on the Pi, and rendering through the Wolfson card?

Absolutely correct! The RPi is hardwired to a gigabit, full duplex network. The Wolfson card's SPDIF output is connected to one of the DAC's input.
I am just not sure if the cause of the clicks is I/O contention. The clicks often occur in complex passages of the song, but never on the same exact moment. It could be that the RPi's CPU is getting overtaxed. The song I chose as reference sometimes would have 3 to 4 clicks during playback, sometimes only 1. In case you are interested, that song is called harmOrgan and is available for free download at 2L - the Nordic Sound. When you visit the page, access the drop-down list at the top right corner and select "Test bench HD Audio Files". You will see a list of available files in different resolutions. To download them you will have to enter credentials which are provided at the top of the page.
 

maestroji

Member
2015-03-10 1:30 pm
I have not had that problem. The Squeezeplug is a complete solution and its version of the OS is optimized to host a headless player. Over the past several months since I assembled the media player, I have cycled it on and off over 100 times with no problems. However, I have never just shut down the player by cutting the power to it. I installed PuTTY on the machine hosting the Logitech Media server and, before shutting it down, I remote into the player and shut it down (shutdown -hP). The player does not currently have a keyboard, mouse or monitor connected to it.

Thanks for posting this. Squeezeplug has been on my list of software to try out, but I'm not going to waste time distro-hopping until Cirrus fixes the underlying kernel/driver problem.

Given that the CirrusLogic kernel won't recognize my KB/Mouse unless I jump through hoops, it looks like I'll be stuck using SSH to control the box as well. It's either that, or constantly unplug/replug the USB devices whenever the kernel stops recognizing them.


In my previous post I included the part numbers for the RPi board and sound card. Please visit MCM Electronics: Home and Pro Audio/Video, Security and Test Equipment and verify if we are talking about the same devices.

We're using the same products -- I reviewed the schematics before buying the device. The "Cirrus" branded version of the Wolfson card is not an upgrade. The circuits and the drivers are the same on the Wolfson Audio Card for the Pi Model 1 B and the "Cirrus" (Wolfson) card for the Pi Model 1 B+. The only thing that is different about the cards is that the add-on board's layout was revised to accommodate the new header layout for the extra GPIO pins on the B+. Otherwise, there has been no "upgrade" to the device. The chips are the same, circuits are the same, schematics are the same, drivers are the same.

I am just not sure if the cause of the clicks is I/O contention. The clicks often occur in complex passages of the song, but never on the same exact moment. It could be that the RPi's CPU is getting overtaxed.

That was my concern as well. My first Pi Model 1 B+ experiments with various flavors of "canned" media distributions showed 100% CPU utilization when attempting to render redbook flac sourced from a gigabit lan on the device's native analog audio port. That problem with ethernet via the USB chip, combined with DA conversion on the Pi, resulted in ongoing stuttering, clicks and pops. The rendering was so awful that I gave up.

The idea of off-loading the DA conversion to the I2C bus seemed like it might make the Pi a viable rendering platform, especially when a local (USA) distributor started offering the cards.

For redbook audio, The B+/Cirrus combination seems to "work" if you can jump through the software hoops -- when playing redbook flac files off of a USB stick while decoding using the Cirrus card, the CPU utilization is only about 15%, with 85% idle. Those numbers are better than 100%, but it's important to note that they don't represent LAN-based streaming, which will add CPU load. Attempting to render at higher resolutions will only make matters worse because the Pi is such a CPU-constrained computing device.

Even with the DAC card to offload some of the CPU load, the Pi Model 1 is still a sluggish excuse for a real-time device. When I bought it, I expected low perf, and I got more of that than I expected. ;)

There's an old saying that the definition of foolish is performing the same experiment over and over again, while expecting a different outcome. I know enough about the defective kernel/driver situation to know that every distribution that relies upon the defective Cirrus drivers is going to have similar problems until the drivers are fixed. Unfortunately, years have passed and things haven't changed. It seems as if all driver development at Wolfson stopped when Cirrus bought the company.

I really don't have interest in putting more time into the Cirrus card on the Raspberry Pi Model 1 because the Model 1 is a sluggish platform, and spending more time on it amounts to wasting time trying to polish a turd. Maybe the situation will improve if/when using the Cirrus card with the quad-core Pi-2 ever becomes a reality. Perhaps new drivers on a quad core chip will fix the CPU utilization problem, and also take care of your problem streaming at 192/24.

Unfortunately, we're still stuck in a wait state while Cirrus continues not to fix the vapor-ware software problem.
 
There exists an Alsa SoC codec driver for the WM5102:

Linux/sound/soc/codecs/wm5102.c - Linux Cross Reference - Free Electrons

Also there are platform drivers for the BCM2835 and BCM2836 (RPi2) SoC's.

What you still are missing are the machine drivers for both RPi and RPi2 which combine the codec and platform drivers. Shouldn't be big job. The wm5102 driver might be so new that it must be backported to raspbian first.
 
This might be a stupid question, but have you tried a generic USB DAC at all (a lowly Behringer UCA202 or whatnot)? From what you write, I'm under the impression that it is mainly the internal PWM audio that is causing high CPU load. Now the RPi is supposed to have pretty pathetic USB (which is unchanged in the new SoC on the version 2), but anyway.

15% playing FLACs is something I would expect from, uh, a Pentium 133 or so? That one would have relied heavily upon DMA though - ISA soundcards always used ISA DMA, and then-current PCI IDE controllers would have supported multiword DMA 2 (making use of which was becoming all the rage in PC circles at the time). And keyboard and mouse input would have been interrupt-driven.

By contrast, USB is traditionally polling-based (and my old PIII system would occasionally drop characters on a USB keyboard if busy), though typical modern USB 2.0/3.0 controllers (EHCI/XHCI compliant) apparently use and rely on DMA nowadays. Unfortunately the one in the RPi is not EHCI compliant and rather pathetic in its abilities, having time-critical operations handled externally, which has been known for a while. Performance has seemingly improved since then, but unfortunately the network is connected via that single USB port, too.
All in all I'm guessing a fair bit of processor power is eaten up by inefficiency - integer performance of the RPi ought to be about on Pentium III 450 level, or more than 3 times as fast as a trusty Pentium 133.

In sum, if you care about USB performance and reliability or network performance, then the RPi probably isn't the single-board computer for you. There are some others with SATA ports and/or onboard Gigabit Ethernet and overall significantly better I/O performance, though usually more expensive (you may have guessed). Depends on how much your time is worth to you, I guess.
 

maestroji

Member
2015-03-10 1:30 pm
Software for Raspberrypi and i2s DAC

is Raspberry Pi 2 compatible with i2s dacs? if so, I'll buy one.

what software can I use? (I can't use linux at all, so can't change kernel, and so on.)

If you have already purchased the Raspberrypi and obtained a suitable software then please ignore the suggestion which follows.

If you need a software and are also interested on a i2s DAC then I could suggest to you the Wolfson Audio Card and the OpenELEC (easy to setup and easy to use) software.

The link to the software is as follows : OpenELEC Mediacenter - Get OpenELEC

If you do opt to get the Wolfson Audio Card then you will need another build to update the official OpenELEC software and the link to this is :
OpenELEC Mediacenter - OpenELEC Forum - Topic: Wolfson Audio Card Support (12/12)

Wishing you success and happy music listening and video viewing.
 
As has been here mentioned several times before - another no-fuss option for audio playback is an x86 thin client. These devices offer PCI ports (+/-12V can be added easily) for soundcard/SATA controller, proper USB ports, some have IDE ports for older HDD, native ethernet (some 1Gbps). But the main advantage - they run the latest linux kernel with the latest audio drivers out-of-box, no backporting drivers to ancient android kernels (3.4) etc. CF cards, MBR booting (also from USB), simple x86 installation.

Consumption - e.g. https://gothian.wordpress.com/leistungsvergleich/leistungsvergleich-linux/

They are available on ebay from banks for prices way below RPi.