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

Driver fixes and updates to kernel 3.18.16 and 4.0.5

hiassoft

Edit: Current kernel versions and install/config instructions are also available from my webpage http://www.horus.com/~hias/cirrus-driver.html

 

During the last few weeks I fixed various issues in the Wolfson/Cirrus driver and rebased it so it works with the current RPi kernel versions (3.18.16 and 4.0.5).

 

You can download the patches from my GitHub repository. The 3.18 kernel with Cirrus drivers is in the cirrus-3.18.y branch, the 4.0 kernel with Cirrus drivers is in the cirrus-4.0.y branch. I'll rebase and update these branches from time to time so that the Cirrus driver and my changes will stay on top of the commit list.

 

If you just want to have an updated 3.18.16 kernel you can download precompiled binaries from here. Just unpack the tarball in the root directory. Before you do that it might be a good idea to update the firmware files (bootcode.bin, start*.elf and fixup*.dat in the boot directory) to the latest version.

 

Here's a list of my changes:

- Added the FLL1 setup back so that switching between 44.1kHz and 48kHz (and other sample rates) works fine.

- Don't register Arizona IRQ if it's set to 0. The Cirrus driver uses polling here and if we register an interrupt handler for irq 0 we get lots of "spurious interrupt" messages spamming dmesg in kernel 3.19 and newer. IRQ 0 is wrong anyway.

- Include DCVDD patches from the Cirrus linux-drivers repository. These patches make sure the WM8804 chip is initialized properly. Without this patch I sometimes had SPDIF audio out only on the right channel.

- Disable spidev0 in Cirrus device tree overlay. That's mainly a safety precaution so that userspace programs trying to access spi0.0 won't interfere with the WM8804 reset line. I'm not 100% sure this is needed at all, so maybe I'll remove it some time later.

 

And some important notes:

I haven't included the mmap patch, this is already supported in the upstream kernels but currently disabled by default. To enable mmap support add the following line to config.txt:

dtoverlay=i2s-mmap

 

If you compile the kernel on your own please note that the devicetree overlays have now been moved to arch/arm/boot/dts/overlays.

 

Kernel 4.0 now uses spi_bcm2835 by default (the older spi_bcm2708 module is available via a devicetree overlay) so you have to extend your /etc/modprobe.d conf file and add a pre-depend for spi_bcm2835 as well. It's safe to have both the old and the new module in here, so just use this configuration:

softdep arizona-spi pre: arizona-ldo1
softdep spi-bcm2708 pre: fixed
softdep spi-bcm2835 pre: fixed

 

so long,

 

Hias

Parents

  • Hi Mathias, and thank you for the work you put into this (i used your guide to setup my soundcard some months ago)
    Now i have a problem with my sound, and i think i have traced it back to the soundcard.. so i'm writing here, since you are the person that comes in mind who would have the knowledge image

     

     

    The problem is this: I am trying to write interleaved samples to the sound buffer using snd_pcm_writei() (link = ALSA project - the C library reference: PCM Interface), but i realized that only one of the earplugs i use is playing sound, the sound frequency is lower and i have noise as well.
    My educated guess is that the samples are not being written interleaved from the soundcard, but rather all samples to one channel, which would also account for the frequency distortion and noise.
    So my question is if there is a way to set up an output to accept interleaved samples?( btw. i use your shells "reset paths.sh" "playback_to_headset.sh" etc in the beginning of my program)

     

    Thanks for your time!
    soren

  • in reply to Former Member

    Hi Soren!

    The problem is this: I am trying to write interleaved samples to the sound buffer using snd_pcm_writei() (link = ALSA project - the C library reference: PCM Interface), but i realized that only one of the earplugs i use is playing sound, the sound frequency is lower and i have noise as well.
    My educated guess is that the samples are not being written interleaved from the soundcard, but rather all samples to one channel, which would also account for the frequency distortion and noise.

    Hmmm, that's odd. Interleaved samples is the default and should work just fine. aplay is also normally using snd_pcm_writei / snd_pcm_mmap_writei when you play a file

    http://git.alsa-project.org/?p=alsa-utils.git;a=blob_plain;f=aplay/aplay.c;hb=HEAD

     

    Check if aplay works and also test if lineout is OK.

     

    If aplay on lineout is fine, but not on headphones out it could just be a bad contact on the headphone jack.

     

    If aplay works fine on headphone out as well then check the samples you write out and also if the sample format is correct.

     

    so long,

     

    Hias

Reply
  • in reply to Former Member

    Hi Soren!

    The problem is this: I am trying to write interleaved samples to the sound buffer using snd_pcm_writei() (link = ALSA project - the C library reference: PCM Interface), but i realized that only one of the earplugs i use is playing sound, the sound frequency is lower and i have noise as well.
    My educated guess is that the samples are not being written interleaved from the soundcard, but rather all samples to one channel, which would also account for the frequency distortion and noise.

    Hmmm, that's odd. Interleaved samples is the default and should work just fine. aplay is also normally using snd_pcm_writei / snd_pcm_mmap_writei when you play a file

    http://git.alsa-project.org/?p=alsa-utils.git;a=blob_plain;f=aplay/aplay.c;hb=HEAD

     

    Check if aplay works and also test if lineout is OK.

     

    If aplay on lineout is fine, but not on headphones out it could just be a bad contact on the headphone jack.

     

    If aplay works fine on headphone out as well then check the samples you write out and also if the sample format is correct.

     

    so long,

     

    Hias

Children
  • in reply to hiassoft

    aplay to lineout and headphones both work fine: correct frequencies, no noise, both channels.

    The buffer in which the samples are stored in before the writei has the same values as i see in matlab when i use audioread (of course interleaved instead of two channels) so this should be fine as well
    This leaves the sample-format: the function i call for reading data from my .wav file is sf_read_int() (link The libsndfile API ), which allows me to read to short, int, float and double. short gives me audio output on both channels, but bad quality (chopped), and int gives me good output on one channel.
    I will look at which format is recognized by sf_open() to check if it matches my 32-bit integers

     

    there is no way to check the actual values written by snd_pcm_writei() right?

  • in reply to Former Member

    I'd say have a closer look at the buffer you pass to snd_pcm_writei, for debugging purposes you can for example just fwrite() it to a file.

     

    Especially chceck if the byte arrangement in the buffer matches the sample format you configured via snd_pcm_hw_params_set_format.

     

    If, for example, you set the format to S16_LE and then pass a buffer of (32-bit) ints to snd_pcm_writei the lower 16 bits of the first sample for the left channel will be used for the left channel, the upper for the the right channel, then the next sample uses the lower 16-bits of the first sample for the right channel for the left channel and the upper bits for the right channel.

     

    That could lead to a similar result as you described - everything is played too slow and you probably get noise on the left channel.

     

    so long,

     

    Hias

  • in reply to hiassoft

    I found the error now image (i was pulling out my hair yesterday because the data was stored correct in 16-bit little endian, and both input and output was set to 16 bit LE)
    The problem was me misunderstanding snd_pcm_writei(). The third input is the number of samples to be written to left and right channel, and not the total number of samples to be written (sum of L and R) as i had assumed. So when i switched the output buffer to shorts, it was giving me 2048 samples of correct data on each channel, and then 2048 0's image

     

    Thanks a lot for the help (even though it didn't relate much to your drivers)

  • in reply to Former Member

    Sometimes having to describe the problem leads to the solution and hence to the understanding involved. Glad to hear you found your answer. High five to for leading you to that understanding.

    Clem