New reworked driver for Wolfson/Cirrus Logic audio card

Hias,

A huge thank-you for all the work you've put into supporting the Cirrus Audio card.  Until now I've been using your kernel packages, and have just got round to trying the latest official 4.9 kernel which is also working very nicely.  It's a real shame that the Cirrus card has (or appears to have) gone out of production just when the software support became so good.  The older Wolfson cards are still available, so perhaps I'll get a couple and try modifying them to fit a 40-pin header.  Anyway, thanks again for everything you've done.  I really do appreciate it.

Tim

The Cirrus Card does seem to be out of stock everywhere - what a shame.  I just started working on an alternative ultrasound sensistive microphone, since the electret type I was using has been out of production for years and is now virtually impossible to get hold of.

What other options are there for recording audio at 192kHz with the Raspberry Pi?

Hi,

Interesting,  I really had not investigated that part of the schematics.  You are right of course  ..... can you not tie the inputs to the bias as the signal leaves the jack socket? Much easier there as you are not working at a microscopic scale.

Let us all know what route you take for the modification  ..... as you rightly note the only way of using the Wolfson device is through this card, so we all need to work on finding the best way forward. Best of luck

Hi John - Is removing R39 on the Wolfson board absolutely essential?

Hystrix

As always Hias is the guru, but (for a direct plug in connection between pi and Wolfson) yes removal of R39 is necessary, otherwise you will be pumping the I2S bit clock directly into the 8804 SPDIF chip CSB pin.

This (and the pogo connector) are the reasons I am looking at a piggy back board .... I do not trust myself on components of that size. The down side of this is board construction and the extra height that is involved in the sandwich as a whole

If you do not want to unsolder R39 and do not want to use a piggy back board, the only alternative is to cut pin 12 out of the 40 way connector on the pi and run a flying lead from the stump of that pin up to pin 3 of the pogo connector on the W (working on cutting one of the tracks on the Wolfson board is in my opinion more difficult than removing R39). If you have no intention of reusing the pi with its expansion header, this is perhaps the easiest modification

Hi John!

The hardware modifications are not to everybodys taste and I am still looking into less obtrusive ways of making the adaptation (using a piggy back board, eg)

Trouble is it needs to be double sided, plated through and gold plated on the 8 "thick" pads! But such a board (with connectors installed) would allow the Wolfson card to plug into a Pi 2/3 with no hardware modifications to either (Hias, if you are reading this, can you confirm that I have not done something stupid like reverse clks or tx/rx?).

Looks like you have pins 3/4 and 5/6 of P5 swapped - the P5 layout (as eg here http://elinux.org/RPi_Low-level_peripherals) is from the bottom side of the board (as opposed to the P1 layout which is from the top side). Pin 1 of P5 is next to the P1 GPIO connector.

Instead of using "hard" gold plated P5 pads you could try ENIG finish - it's cheaper and should be OK (though not as durable as hard gold).

You'd probably need to make the PCB full-size so you can add mounting screws for the Wolfson card and the RPi2/3. Then mechanical stability should be OK.

Other than these issues your approach look fine!

so long,

Hias

Ha! I was just looking at those pogo pin connections myself.  From the photo, it looks like the connections are:

P5 Pin 3 to GPIO Pin 12

P5 Pin 4 to GPIO Pin 35

P5 Pin 5 to GPIO Pin 38

P5 Pin 6 to GPIO Pin 40

And remove R39.

Are those the only chnages to make?  On the piggy-back board, what is that connection on GPIO Pin 33 on the 40 pin header and GPIO Pin 12 on the 26 pin header?

Many thanks :-)

It's a shame that the Wolfson card doesn't have Line In micbias, but I could live with that.

Looking at the schematic it seems you can add it quite easily: remove C8 (it's next to the WM5102), then connect that to 2 2k2 resistors and solder the other end to line in (junction between R55/L6/C33 and R56/L7/C32). Then it'd be like the Cirrus card.

Taking Micbias from the headset in would also be a possibility, just remember that'd you'd need to enable Headset input as well (you could just do a "cirrus-listen headset headset" then micbias on headset in will always be on).

Is removing R39 on the Wolfson board absolutely essential?

Yes. During reset pin 5 of the WM8804 is used as in input to select the I2C address - so you need to have it connected to the pullup. Afterwards it's an output so if you leave it connected to P1 header pin 12 it'd clash with the I2S clock. I haven't found an easier way to cut the connection from GPIO pin 12 to the WM8804 so removing the in-line 0R resistor R39 seems to be the easiest method ATM.

so long,

Hias

Hystrix

See Hias comment, it looks as though I have mirrored the J5 pins, so wait for the revised diagram! Sorry!  But the link you are referring to provides the correct connection back to the 8804.  That is done for completeness, because as Hias says, the pin on the 8804 can be left open circuit without a problem.

The minimum set of connections are just as you say.

As per Hias suggestion, I had thought of making the piggy back card "full size" so that it can offer mechanical support.  At the moment I am thinking of what else to use the card space for.  I need to drive a relay(!) based digital attenuator for the output of the Wolfson, so I will probably put a couple of I2C ports on the card.

Hias,

Once again, thank you for your help

And herewith the revised pcb

Hi John - thanks for the update.

Now all I have to do is find the elusive R39.  I only had a quick look last night.

Now all I have to do is find the elusive R39. I only had a quick look last night.

 

It's on the bottom side of the PCB, near the mounting hole.

so long,

Hias

Now all I have to do is find the elusive R39. I only had a quick look last night.

 

It's on the bottom side of the PCB, near the mounting hole.

so long,

Hias

Hias and John,

I got my "Frankenson" sound card working with a Pi2 .

I didn't de-solder the pogo pins.  I found a cover that fits over them nicely - made from a UK 3-pin mains plug protector that all new electrical devices come with.  I cut the end off the Earth pin end of the protector.  It fits neatly onto the pogo pins.  Once the Wolfson card is attached to the Pi, the cover is held nicely in place, and stops them shorting on anything on the Pi.

Here's the pogo cover made from a plug protector:

Thanks for your help with this neat hack.

Hystrix

Bravo, I like it.  One of the positive british traits that, improvisation.

I knew UK plugs would prove better one day .... It has only taken 60 years  ..... Ironically I cut the last one off my appliances only this week.

More seriously, note that there is a wee bit of strain introduced by the pin protector, perhaps raise the Wolfson card a millimetre to compensate.

I have just made the mark 1 piggy back board, so if I can get the single sided version to work, expect photos of that too.  It's good to see an active community

Ha!  I knew someone would mention the strain caused by the pogo pin protector.    This was an early photo - I actually trimmed off some more of the plastic on the left-hand side.  You can see the black header is catching on it in the photo - it's much better now.

My only concern is whether the springs in the pogo pins will eventually start to push the audio card off the header.  Time will tell.  I may even file off some of the plastic from the bottom of the pin protector, so the springs aren't compressed as much.

I look foward to the photos of the piggy-back board.

I got my "Frankenson" sound card working with a Pi2 .

 

I didn't de-solder the pogo pins. I found a cover that fits over them nicely - made from a UK 3-pin mains plug protector that all new electrical devices come with. I cut the end off the Earth pin end of the protector. It fits neatly onto the pogo pins. Once the Wolfson card is attached to the Pi, the cover is held nicely in place, and stops them shorting on anything on the Pi.

That's looking really nice, well done! And I think the cap over the pogo pins is a rather clever idea!

so long,

Hias

Matthias,

Really sorry to bother you, but having got my piggy back +pi 3 working, I played with the kernel. Fatal mistake.  I had been running Runeaudio + your(?) 4.4.14 kernel, but I have messed up.  I could spend days finding the problem (and 5 minutes fixing it), but perhaps it is time to leave the past behind. What kernel would you recommend to run headless MPD, with linux shell available over SSH and the ability to run brutefir? It sounds like I dont need Jessie (which you kindly support) nor the librelec kernel (which you kindly support).

Many thanks in advance

Hi John!

What kernel would you recommend to run headless MPD, with linux shell available over SSH and the ability to run brutefir? It sounds like I dont need Jessie (which you kindly support) nor the librelec kernel (which you kindly support).

I'd recommend using Raspbian Lite (Jessie), this is what I'm using for my (mostly headless) test setups as well. The Lite version comes with a minimal set of packages preinstalled, no desktop environment and unnecessary cruft for headless setups, and you can easily install the packages you want. mpd and brutefir are all available from the Raspbian repo, "sudo apt-get install mpd brutefir" and you can get going Ah, well, and "sudo rpi-update" for the 4.9 kernel with cirrus drivers plus downloading the mixer scripts, of course

so long,

Hias

Matthias,

As always, thanks for the rapid reply.  It all went smoothly, though not as quickly as I would like.  Below I have listed the steps I took in painstaking detail ....  Obviously this is stuff you already know!  But if somebody else wants to do the same thing, it saves you from having to reply.  Your instructions at RPi Linux driver for Wolfson / Cirrus Logic Audio Card are concise and 100% correct.  Here I just spell it out.

1) Download jessie lite and unzip it from the base repository

2) In a terminal on a linux machine with a blank memory card inserted (at device $)

        sudo dd bs=4M if=2017-03-02-raspbian-jessie-lite.img of=/dev/sd$

3) SSH is enabled in jessie by creating a file with name "ssh" in the boot partition

4) Install card and boot pi (with wired ethernet)

5) SSH to device  ssh $.$.$.$ -l pi (password=raspberry), thence

    sudo apt-get install rpi-update

    sudo rpi-update (y at prompt.  We do this to get the 4.9 kernel to get the driver for the Wolfson)

    sudo raspi-config (to enable i2c and spi, follow the menus)

    sudo reboot

6) SSH to device (again)

    uname -a (just to check at kernel 4.9)

    sudo apt-get install mpd brutefir (to install my tools for later)

(this failed, so)

    sudo apt-get update

    sudo apt-get install mpd brutefir (to install my tools for later)

(locale warnings from perl, but unpacks a lot more, esp stuff for brutefir like fft)

    sudo apt-get install mpc (useful add on to mpd)

    sudo apt-get install i2c-tools (to check device presence.  8804 on card shows at 3b using  sudo i2cdetect -y 1)

    sudo apt-get install vim to get vim editor (easier to edit through SSH than playing the permissions game through ftp)

(you could wrap all those gets up into a single line, skip the reboot etc, this is just my log!)

   sudo vim /boot/config.txt (uncomment #dtparam=i2s=on and add the line "dtoverlay=rpi-cirrus-wm5102")

    sudo vim /etc/modprobe.d/cirrus.conf (to create new file, with content "softdep arizona-spi pre: arizona-ldo1")

    sudo reboot

SSH to device

At this point aplay -l shows the (piggy backed) Wolfson card and alsamixer allows you to play with it

(Apologies to all, I must learn the correct protocol for doing this on the board)

Postscript,

The rest of getting the new system working went very smoothly, a bog standard MPD configuration and moving the system to run from HD (I don't like writing to SD ad infinitum) .  The only hiccup came when I imported my alsactl state file (alsactl allows you to store and restore complete configurations for the sound card, very useful when playing with something as complex as this sound card).  Matthias has indicated in an earlier post that the driver had changed and so my import failed    ...... my own silly fault .......

alsactl: set_control:1325: failed to obtain info for control #36 (No such file or directory)        (ditto 37,38,39)

alsactl: set_control:1325: failed to obtain info for control #162 (No such file or directory)

alsactl: set_control:1325: failed to obtain info for control #298 (No such file or directory)       (ditto 299,300,301)

alsactl: set_control:1325: failed to obtain info for control #461 (No such file or directory)       (ditto 462,463,464)

The first group are the EQn filter equalisation parameters, which I use as a partial room correction filters....... in fact a large number of other controls have changed numbering too, so I do not suggest this path for migrating parameters

So now a few tweaks and I am done!

(Matthias,  I remember you mentioning the EQ parameters changing from 42 to 40 bytes, so no need to reply, unless you want to.  It is only when you look at the state file that you realise how enormous the driver is.  Yet again, many thanks)

Matthias,

It is a 100 to one shot I know, but by any chance did you compile WISCEbridge support into your driver?  (From what I can find WISCEbridge allows raw register read/write through ports 22348/22349 using a "simple" protocol)  I am guessing not, but it has proved impossible for me to find a copy of WISCEbridge for Linux (which is in the WISCE SDK).

From an ideological point of view, I am guessing that it would not be correct to integrate what would effectively be a back-door for this control route into the driver for the 5102. I ask because I would like to know what you would see as the correct way of setting up the EQ parameters .... raw writes to your driver, a cosmetic layer or direct access to the registers via i2c/spi (I've rewired one of my Wolfson to make the 5102 visible on i2c).  Of course direct access could well give rise to clashes with your driver.

So I am guessing I have many happy evenings with wireshark ahead of me!

Hi John!

It is a 100 to one shot I know, but by any chance did you compile WISCEbridge support into your driver? (From what I can find WISCEbridge allows raw register read/write through ports 22348/22349 using a "simple" protocol) I am guessing not, but it has proved impossible for me to find a copy of WISCEbridge for Linux (which is in the WISCE SDK).

 

I didn't have much luck with WISCE so far. Downloaded the latest version (3.6.1.3) and installed the WM5102 setup from cirrus.com but I just got an error message when trying to create a simulation project. WISCE log says "Internal Error - WARNING: Firmware on WM5102's DSP1 core is NOT valid" - not sure what's going wrong there.

Do you have the original installation files and could you upload them somewhere?

As for direct register access: I wrote a simple program to do that, via I2C, needed that for debugging as well http://www.horus.com/~hias/tmp/cirrus-reg.c

The kernel driver accesses the WM5102 chip via SPI but the chip is also connected via I2C. The I2C interface is only available when the chip is active (i.e. not in standby), so you either need to have aplay/arecord running in the background or run a listen script - otherwise the WM5102 will enter standby mode and only react on SPI.

As for the EQ registers: WM5102 has 21 16-bit registers for each equalizer, EQ1 registers are 0xE10-0xE24. The first 2 registers control the 5 band volumes and are exposed via alsa mixer controls ("EQ1 B1 Volume" .. "EQ1 B5 Volume"). The EQ enable bit in the first EQ register is controlled via DAPM, that means whenever you route signals through the EQ it'll automatically be enabled.

The mixer control "EQ1 Coefficients" sets registers 0xE11-0xE24 - which means they overlap with the B4 and B5 controls in 0xE11.

For details about the register and mixer definitions look at include/linux/mfd/arizona/registers.h and sound/soc/codecs/wm5102.c in the kernel tree - just search for _EQ1_

so long,

Hias