Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
Forum Thread Details
  • Replies 165 replies
  • Subscribers 715 subscribers
  • Views 27000 views
  • Users 0 members are here
Related

Cirrus Logic Audio Card working on the Raspberry Pi 2

e14 Contributor

Hi all!

 

As you might know, Cirrus Logic's main kernel source branch recently switched to 3.18.

My first thought was "Hmm, that means the Cirrus Logic card could finally work on the RPi2..."

I have built a couple of 3.18 kernels for my B+ and RPi2 and I have managed to get both models to produce sound image

 

It's still early days, i.e. there are possibly bugs and glitches to fix, but for those of you who would like to try it out I've made an image file that you can download here:

https://drive.google.com/file/d/0BzIaxMH3N5O1cmJ1bFhMcG1hc0E/view?usp=sharing

The file is a 1.3 GB zip. Uncompressed size is 3.1 GB, so it fits comfortably on a 4 GB card.


The image is based on the standard 2015-02-16-raspbian-wheezy image from the Foundation that you flash to a SD card for a fresh install.

I have only added my kernels and set up the configuration files to get the card going.

It should work on the older B model  with a Wolfson Audio Card too, but I haven't tested that yet.

 

Have fun!

--

Ragnar

  • in reply to e14 Contributor

    But, jack_control has only one purpose; to control jack-dbus. It's a python script, it isn't configured or built, just copied.

    So there is no need for jack_control if I want to run it headless anyway?

     

    I removed all jack files and started over, this time I used a prefix to install it directly into /usr/bin

    ./waf configure --alsa --prefix /usr/

     

    The jackd executes fine, but I did not find a client who was able to connect. This was working at least partially with the JACK1 version from the raspbian repository.

     

    pi@raspberrypi2 ~/jack2 $ jackd  -P70 -p16 -t2000 -d alsa -dhw:sndrpiwsp -p 1024 -n 3 -r 44100 -s
jackdmp 1.9.11
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2014 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK server starting in realtime mode with priority 70
self-connect-mode is "Don't restrict self connect requests"
creating alsa driver ... hw:sndrpiwsp|hw:sndrpiwsp|1024|3|44100|0|0|nomon|swmeter|soft-mode|32bit
configuring for 44100Hz, period = 1024 frames (23.2 ms), buffer = 3 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 3 periods for capture
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 3 periods for playback

     

     

    pi@raspberrypi2 ~/jack2 $ jack_simple_client 
unknown option character l
connect(2) call to jackdmp 1.9.11/jack-1000/default/jack_0 failed (err=No such file or directory)
jackdmp 1.9.11
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2014 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
`default' server already active
Failed to open server
connect(2) call to jackdmp 1.9.11/jack-1000/default/jack_0 failed (err=No such file or directory)
connect(2) call to jackdmp 1.9.11/jack-1000/default/jack_0 failed (err=No such file or directory)
connect(2) call to jackdmp 1.9.11/jack-1000/default/jack_0 failed (err=No such file or directory)
connect(2) call to jackdmp 1.9.11/jack-1000/default/jack_0 failed (err=No such file or directory)

  • in reply to e14 Contributor

    Hello Martin, what are your plans with the RPi?

  • in reply to e14 Contributor

    Hi Jeremy, I am trying to setup a low latency audio system for filtering etc. I might even get into AMP with some RTOS but getting the cirrus board to work in bare metal might take to long.

    So for now it is just the RT kernel JACK and maybe Supercollider or pure C.

  • in reply to e14 Contributor

    Dear Ragnar Jensen,

    Regarding the .deb files you offered on Apr 13, 2015 (in this post):  Can you confirm that these debs are good to apply to the (more recent) raspbian release by the foundation on 2015-05-05. 

    I've been silently following this thread, and can not thank you enough for your help.  It's made a huge difference to my project, and I am very very grateful. I'd still be stuck in the world of USB microphones without your assistance.

    Regards,

    jcjc.





  • in reply to jcjc

    Hi J C!

     

    Yes, the .deb package works on the 2015-05-05 Raspbian image.

    You also need the overlay file and the use case scripts. It might be easiest to extract them from the tar file I mention in the second post of this thread.

     

    It's made a huge difference to my project,


    OK, I'm curious  image What is it you're doing?

    --

    Ragnar

  • in reply to e14 Contributor

    Ragnar,

     

    > OK, I'm curious  What is it you're doing?

     

    It's a field audio recorder for long-term outdoor deployments,

    recording audio around the clock.  My motivation is

    environment/wildlife monitoring.  With a standard USB battery pack, a

    Raspberry Pi A+, and a Cirrus card, I can get over 5 days of constant

    16kHz recordings.  Bigger battery (car?) and bigger SD card, and you

    can grow the deployment time, of course.  Data is stored on the MMC SD

    card, on a bespoke partition (p3).

     

    I want to be able to provide users with an .img that requires no

    configuration at all - except perhaps some tailoring via a

    /boot/user.conf file, for things like volume and input source

    (DMIC/headset/line-in). Such a file is accessible (even on windows)

    once the card is flashed, so reasonably easy for non-technical users

    to handle.  ... And it all works with your .debs.  Fantastic.

     

    Encouragingly, it appears that even on systems _without_ a Cirrus card

    attached, your kernels boot and appear to work (I support USB

    microphones/dongles too for those who don't have a Cirrus card).  Is

    there any reason why this might be dangerous?  It looks like the code

    tries to initialize the non-existent Cirrus card a few times,

    "requests probe deferral" - then we hear no more from it.  From dmesg:

     

    [    6.094094] bcm2708_i2c 20804000.i2c: BSC1 Controller at 0x20804000 (irq 79) (baudrate 100000)
[    6.427599] DC_1V8: 1800 mV 
[    6.472201] DC_5V: 5000 mV 
[    6.718453] bcm2708_spi 20204000.spi: master is unqueued, this is deprecated
[    6.994185] LDO1: 1200  1800 mV at 1200 mV 
[    7.105399] LDO1: supplied by DC_1V8
[    7.210706] arizona spi0.1: Unknown device ID: 0
[    7.327676] bcm2708_spi 20204000.spi: SPI Controller at 0x20204000 (irq 80)
[    7.359934] usbcore: registered new interface driver snd-usb-audio
[    7.442388] random: nonblocking pool is initialized
[    9.135806] snd-rpi-wsp sound: ASoC: CODEC DAI wm5102-aif1 not registered
[    9.144719] snd-rpi-wsp sound: Failed to register card: -517
[    9.152440] platform sound: Driver snd-rpi-wsp requests probe deferral
[   11.134298] snd-rpi-wsp sound: ASoC: CODEC DAI wm5102-aif1 not registered
[   11.146184] snd-rpi-wsp sound: Failed to register card: -517
[   11.154436] platform sound: Driver snd-rpi-wsp requests probe deferral
[   11.701777] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[   12.358128] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[   15.247859] snd-rpi-wsp sound: ASoC: CODEC DAI wm5102-aif1 not registered
[   15.273573] snd-rpi-wsp sound: Failed to register card: -517
[   15.289914] platform sound: Driver snd-rpi-wsp requests probe deferral
[   17.375872] snd-rpi-wsp sound: ASoC: CODEC DAI wm5102-aif1 not registered
[   17.399127] snd-rpi-wsp sound: Failed to register card: -517
[   17.411977] platform sound: Driver snd-rpi-wsp requests probe deferral

     

    Feels like it would be better, however, if one could probe for some

    indication of the presence of the Cirrus board - via i2c-tools? - and

    (if present) load kernel modules to support it.  But perhaps I

    shouldn't care...

     

    I aim to distribute only one O/S ".img", supporting both generations

    of Pi (arm7 and original), each capable of supporting the Cirrus Card

    (and not).  It seems that raspbian has the intelligence to work out -

    pre-booting - which stock kernel to boot (v7 or traditional) depending

    on the underlying Raspberry Pi hardware, and I hope to tweak those

    kernel pointers to point at the Cirrus-enabled kernels.  But I don't

    know if I'll succeed in working out how to do this.  I fear it's

    hiding in the non-open bits of the boot process (GPU firmware blob, or

    some such thing...).  Advice or pointers appreciated.

     

    FYI, I use the PiFace shim RTC clock (to time-stamp the audio

    recordings) in conjunction with the Cirrus Card, and it works fine,

    appearing as an i2c device as usual.  No conflicts as far as I can

    see.  It fits snugly under the Cirrus board.

     

    And that's that.  You did ask!

     

    Cheers,

     

    James.

  • in reply to jcjc

    Interesting project!

    Encouragingly, it appears that even on systems _without_ a Cirrus card

    attached, your kernels boot and appear to work (I support USB

    microphones/dongles too for those who don't have a Cirrus card).  Is

    there any reason why this might be dangerous?

    No.

    It looks like the code tries to initialize the non-existent Cirrus card a few times,

    "requests probe deferral" - then we hear no more from it.

     

    Feels like it would be better, however, if one could probe for some

    indication of the presence of the Cirrus board - via i2c-tools? - and

    (if present) load kernel modules to support it.  But perhaps I

    shouldn't care...

    I wouldn't care, because that's what the kernel already does.

    The device tree overlay file tells the kernel to load the driver for the Cirrus card. If the driver determines that there is no card, it just exits.

     

    It seems that raspbian has the intelligence to work out -

    pre-booting - which stock kernel to boot (v7 or traditional) depending

    on the underlying Raspberry Pi hardware, and I hope to tweak those

    kernel pointers to point at the Cirrus-enabled kernels.  But I don't

    know if I'll succeed in working out how to do this.

    Yes, the boot loader (the non-open blob) works out what hardware it is running on.

    If there is a "kernel=..." line in /boot/config.txt it will load that kernel.

    If no specific kernel is pointed out in /boot/config.txt, it will select kernel.img on older hardware and on the RPi2B it will select kernel7.img

    So, the easiest way is to install both deb packages, rename the kernel files to kernel.img and kernel7.img and make sure that no kernel is pointed out in config.txt.

    That's the approach I took on the Raspbian image in the very first post of this thread.

    --

    Ragnar

  • For those interested I've uploaded the following packages to my Raspbian repository (http://rpi.autostatic.com/):

    • linux-image-cirrus: meta package that installs a kernel with Wolfson/Cirrus Logic audio interface support
    • cirrus-config-overlay: package that installs the device tree overlay file for the Wolfson/Cirrus Logic audio interface
    • cirrus-config-modprobe: package that installs the modprobe config file for the Wolfson/Cirrus Logic audio interface
    • cirrus-config-scripts: package that installs the playback, record and reset scripts for use with the Wolfson/Cirrus Logic audio interface
    • cirrus-config: meta package that installs all the above packages

    If anyone is interested in testing these packages, go ahead, feedback is greatly appreciated. On a clean Raspbian install adding my repo, installing the cirrus-config package and rebooting your RPi should enable the Wolfson/Cirrus Logic audio interface. No need to edit any config files.

     

    Jeremy

  • in reply to e14 Contributor

    I tried, jeremy. it rendered my pi (temporarily) unusable after reboot. something must have gone wrong, I figure. this was a (quite fresh) 2015-05-05 image on a pi2.

    fortunately I have a spare sd card where I will put the clean image onto and see where I can find a difference.

  • in reply to e14 Contributor

    Hi Markus, sorry about that. I already know what the cause is, working on it.