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.

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.

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.

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 (http://www.horus.com/~hias/tmp/opene...6-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.

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:

An externally hosted image should be here but it no longer works. Please upload images instead of linking to them to prevent this.

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:

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.

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.*

Quote:

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.

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?