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

Cirrus Logic Audio Card working on the Raspberry Pi 2

Former Member

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

Parents Reply Children
  • in reply to Former Member

    Hi Ragnar!

     

    Thank you for uploading, last night i installed the patch and changed the kernel comment.
    After that the system booted succesfully with a new kernel, and im playing with some 24bit-192khz flacs,
    its seems ok, but it would be better if i have a test file. If you could generate some sine wave

    files with different samplerates and bit depth i will try it with a freq. analiser at the end of the amp. chain.

     

    Or do you have a better idea for easy testing?

     

    If there is a terminal command or software to generate the sine waves, i will generate it on my own, with a little help.

     

    Thanks a lot!

     

    Viktor

  • in reply to Former Member

    I forget that, i test it with a timer, 20seconds of playing (kodi showing the elapsed play time) it seems really 20seconds
    measured by the timer on my phone. It will be more precise if i measure the whole track play time, i know, but it was really
    late..:)

     

    Viktor

  • in reply to Former Member

    If there is a terminal command or software to generate the sine waves, i will generate it on my own, with a little help.

    You can do this with sox (just do an "apt-get install sox" if you don't have it installed).

     

    For example: stereo 16-bit WAV at 44.1kHz samplerate with a 10 second 440Hz tone at -3dB:

    sox -n -c 2 -r 44100 -b 16 440-cd.wav synth 10 sin 440 gain -3

     

    Change the -r and -b options for different samplerates / bits per sample.

     

    so long,

     

    Hias

  • in reply to hiassoft

    Hi,

     

    Ok, thanks, i will reply if i have any news.

     

    Viktor

  • in reply to hiassoft

    Hi!

    Good news, it seems perfect:)
    I was generated 3samples
    44100 16
    48000 24
    96000 24

    these are the regular formats for high quality coded flacs from the russians:)pl

     

    Installed freq analizer on my phone and it tells 441Hz for the 440Hz sample, so i think
    its okay, anyway i not recognized the wa-wa thing after i installed the patch.

     

    If i have some time i will make some test with the old config just for sure.

     

    Thanks!!

     

    Viktor

  • in reply to Former Member

    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 Former Member

    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