Added support for Wolfson Audio Card by Element-14 on Raspberry Pi Model B

[manish-wolfsonmicro]

Hi All,

Last pull request where I was trying to push the support for Wolfson Audio Card , somehow got broken.

This is a fresh pull request with reference to the last pull request i.e.
"Added support for Wolfson Audio Card by Element-14 #672 "

Please find the patches to support Element 14 Wolfson Audio Card.

This patch-set addresses feedback comments on the previous pull request.

The patch bundle includes the machine driver and few other supporting patches to offer the functionality of WM5102 and WM8804 codecs drivers.

The current patch-set does not support SPDIF functionality. We are working on a patch-set that will be pushed to the mainline Kernel and
once these have been merged we will submit them for adding them into the raspberry-pi kernel.

For your reference, the following link takes you to the official product page.
http://www.element14.com/community/community/raspberry-pi/raspberry-pi-accessories/wolfson_pi?CMP=KNC-EU-RPI-ACC-Wolfson

~Manish Gupta

[popcornmix]

@hifiberry @koalo @hmbedded @iqaudio
Does this looks okay for existing rpi sound card users?

[MilhouseVH]

I don't have Wolfson (or any other) hardware connected to my Pi B running a 3.17.y kernel, but this PR seems to be responsible for spamming dmesg at startup with "AVDD" and "DCVDD" messages: http://sprunge.us/aTLd (8 second mark)

If I modprobe snd_soc_pcm5102a, I'll get a few more AVDD/DCVDD messages: http://sprunge.us/fjCV (372 second mark)

And then with modprobe snd_soc_hifiberry_dac (I don't have a Hifiberry DAC connected) a few more: http://sprunge.us/XeJd (395 second mark)

[iqaudio]

There are several parts of the i2s code which appear to be Wolfson specific - not sure the i2s code is the right location for these but as I don't have an overall view of the rational behind this I may be misinterpreting the code.

Gordon
On 8 Oct 2014, at 18:21, popcornmix notifications@github.com wrote:

@hifiberry @koalo @hmbedded @iqaudio
Does this looks okay for existing rpi sound card users?

—
Reply to this email directly or view it on GitHub.

[HiassofT]

Could you please tell us which modules need to be loaded? Having an lsmod of a working kernel would help me a lot.

I tested the current MilhouseVH OpenELEC build with kernel 3.17.0 and couldn't get it working. I also noticed that arizona spi0.1: couldn't allocate an IRQ. Could be an issue on my side or with kernel 3.17, though.

I posted some test results here: http://forum.xbmc.org/showthread.php?tid=192380&pid=1810103#pid1810103

[manish-wolfsonmicro]

Hi Dom,

I have incorporated the changes suggested in the updated patch set.

Thanks
~Manish

[manish-wolfsonmicro]

Hi MilhouseVH ,

If you see carefully into the logs the spamming dmesg at startup with "AVDD" and "DCVDD" messages ,they are not due to the wolfson driver modules but pcm512x .
Please try adding this to the blacklisted modules while you are trying to work on wolfson audio card.

blacklist snd_soc_pcm512x

~Manish

[manish-wolfsonmicro]

Hi HiassofT,

I think you are missing the following modules in your list :

./kernel/drivers/spi/spi-bcm2708.ko
./kernel/drivers/i2c/busses/i2c-bcm2708.ko

~Manish

[HiassofT]

The bcm2708 spi and i2c modules are built into the kernel and I also can see the spi/i2c info in the /sys tree. For reference, here's the kernelconfig of the Milhouse OpenELEC build: http://sprunge.us/JgUV

Currently I have the following modules blacklisted:

blacklist lirc_rpi
blacklist lirc_dev
blacklist snd_soc_pcm512x
blacklist snd_soc_pcm512x_i2c
blacklist snd_soc_tas5713

After startup these modules are loaded:

arizona_ldo1            2335  0
fixed                   1425  0
snd_soc_bcm2708_i2s     5585  0
snd_soc_wm8804          7092  0
regmap_mmio             2181  1 snd_soc_bcm2708_i2s
regmap_i2c              1974  1 snd_soc_wm8804
arizona_spi             1109  0
snd_soc_core          104264  2 snd_soc_wm8804,snd_soc_bcm2708_i2s
regmap_spi              1465  2 snd_soc_wm8804,arizona_spi
snd_compress            7084  1 snd_soc_core
snd_pcm_dmaengine       2935  1 snd_soc_core
snd_pcm                63094  3 snd_soc_wm8804,snd_soc_core,snd_pcm_dmaengine
snd_timer              17712  1 snd_pcm
snd                    41549  4 snd_soc_core,snd_timer,snd_pcm,snd_compress
bcm2708_rng              812  0

Here's the dmesg output: http://sprunge.us/LeEU

The AVDD/DCVDD failed messages are still present. At 95 seconds I loaded snd-soc-pcm5102a. arizona spi0.1 then detected a WM5102 but failed to allocate IRQs.

After that I manually loaded the following modules:

arizona_i2c
gpio-arizona
extcon-arizona
snd-soc-wm5102
snd-soc-wm-adsp
snd-soc-rpi-wsp

At 1198 I loaded the last module and got a dmesg entry from snd-rpi-wsp (wm5102 codec not registered).

Here's a full list of the loaded modules at this point, also note the very high reference count of 'fixed'

Module                  Size  Used by
snd_soc_rpi_wsp         7123  0 
snd_soc_wm5102        308081  0 
snd_soc_wm_adsp        15949  1 snd_soc_wm5102
snd_soc_arizona        16599  2 snd_soc_wm5102,snd_soc_wm_adsp
extcon_arizona         11196  0 
extcon_class            8790  1 extcon_arizona
gpio_arizona            1495  0 
arizona_i2c             1133  0 
snd_soc_pcm5102a        1050  0 
arizona_ldo1            2335  0 
fixed                   1425  2147483647 
snd_soc_bcm2708_i2s     5585  0 
snd_soc_wm8804          7092  0 
regmap_mmio             2181  1 snd_soc_bcm2708_i2s
regmap_i2c              1974  2 snd_soc_wm8804,arizona_i2c
arizona_spi             1109  0 
snd_soc_core          104264  8 snd_soc_arizona,snd_soc_wm5102,snd_soc_wm8804,snd_soc_wm_adsp,extcon_arizona,snd_soc_rpi_wsp,snd_soc_pcm5102a,snd_soc_bcm2708_i2s
regmap_spi              1465  2 snd_soc_wm8804,arizona_spi
snd_compress            7084  1 snd_soc_core
snd_pcm_dmaengine       2935  1 snd_soc_core
snd_pcm                63094  5 snd_soc_arizona,snd_soc_wm8804,snd_soc_core,snd_soc_rpi_wsp,snd_pcm_dmaengine
snd_timer              17712  1 snd_pcm
snd                    41549  4 snd_soc_core,snd_timer,snd_pcm,snd_compress
bcm2708_rng              812  0 

[MilhouseVH]

If you see carefully into the logs the spamming dmesg at startup with "AVDD" and "DCVDD" messages ,they are not due to the wolfson driver modules but pcm512x .
Please try adding this to the blacklisted modules while you are trying to work on wolfson audio card.

blacklist snd_soc_pcm512x

Hi Manish

Yes, and I also see Arizona being mentioned, which is a module included/referenced by this PR.

The problem is, I'm seeing these errors when I don't have Wolfson hardware connected, and expecting the vast majority of users (that won't have Wolfson hardware) to have to now start blacklisting modules due to problems created by this PR doesn't sound like the right way to proceed.

If I were seeing these errors when I explicitly loaded a Wolfson module (whichever ones they might be) then I could understand and accept the need to blacklist snd_soc_pcm512x. However seeing these errors when no new modules have been loaded (and I don't have Wolfson hardware connected) suggests the kernel config is not as it should be, and your code is causing undesirable interactions that should only occur when the user explicitly requests your modules to be loaded.

[MilhouseVH]

As a test I created /storage/.config/modprobe.d/disable-pcm512x.conf:

blacklist snd_soc_pcm512x
blacklist snd_soc_pcm512x_i2c

but I'm still getting dmesg spam: dmesg, lsmod.

[iqaudio]

Pcm512x should not have anything to do with AVDD etc.

Please check the bcm2708.c changes (line 677?)

Is this due to "Config_regulator_fixed_voltage" definitions?

Gordon

Gordon

On 10 Oct 2014, at 10:59, MilhouseVH notifications@github.com wrote:

If you see carefully into the logs the spamming dmesg at startup with "AVDD" and "DCVDD" messages ,they are not due to the wolfson driver modules but pcm512x .
Please try adding this to the blacklisted modules while you are trying to work on wolfson audio card.

blacklist snd_soc_pcm512x

Hi Manish

Yes, and I also see Arizona being mentioned, which is a module included/referenced by this PR.

The problem is, I'm seeing these errors when I don't have Wolfson hardware connected, and expecting the vast majority of users (that won't have Wolfson hardware) to have to now start blacklisting modules due to problems created by this PR doesn't sound like the right way to proceed.

If I were seeing these errors when I explicitly loaded a Wolfson module (whichever ones they might be) then I could understand and accept the need to blacklist snd_soc_pcm512x. However seeing these errors when no new modules have been loaded (and I don't have Wolfson hardware connected) suggests the kernel config is not as it should be, and your code is causing undesirable interactions that should only occur when the user explicitly requests your modules to be loaded.

—
Reply to this email directly or view it on GitHub.

[MilhouseVH]

Has anyone had any success with this PR?

[iqaudio]

Sorry, still waiting on feedback on why the wolfson specific changes are in the i2s code.

Same with the AVDD etc.

Gordon

[HiassofT]

I had a little bit more success with kernel 3.12 and a fresh raspbian installation.

After a lot of trial-and-error I ended up with this /etc/modules file:

#snd-bcm2835

spi-bcm2708
i2c-bcm2708
arizona-spi
snd-soc-wm5102
snd-soc-pcm5102a
snd-soc-wm8804
snd-soc-rpi-wsp

Here are lsmod and dmesg with a Wolfson card plugged in. Here are lsmod and dmesg without the card using the default /etc/modules file, containing only snd-bcm2835.

After bootup I ran the Playback_to_Lineout.sh script and was able to play a wav with aplay.

However, there are some issues:

There's a kernel backtrace in dmesg.

Audio output volume is very low compared to the 3.10 kernel with wolfson drivers. Playing a 440Hz 0dB file gives only 23mV RMS on lineout (into a 10k ohm load), on my OpenELEC build with kernel 3.10 plus previous Wolfson patches I measured 955mV RMS.

And: please provide some documentation which modules need to be loaded. Having to figure out by myself which modules are needed (and, really a lot seem to be needed) was no fun at all! Maybe adding a MODULE_SOFTDEP to snd-soc-rpi-wsp might help, currently only snd-soc-core and snd-pcm are listed.

[manish-wolfsonmicro]

Hi ,

Please include the following modules list in the file:

bcm2708-rng
snd-bcm2835
gpio_arizona
arizona_micsupp
snd_soc_bcm2708_i2s
snd-soc-arizona
snd-soc-wm-adsp
snd-soc-wm5102
snd-soc-rpi-wsp

and you will be able to see both the base board audio and wolfson sound audio card detected in the aplay -l list .

~Manish

[HiassofT]

On Thu, Oct 23, 2014 at 10:58:46AM -0700, manish-wolfsonmicro wrote:

Please include the following modules list in the file:

bcm2708-rng
snd-bcm2835
gpio_arizona
arizona_micsupp
snd_soc_bcm2708_i2s
snd-soc-arizona
snd-soc-wm-adsp
snd-soc-wm5102
snd-soc-rpi-wsp

This doesn't look like it's complete module list - spi-bcm2708
seems to be missing. And: what's bcm2708-rng needed for?

Please provide a full, but minimal /etc/modules file that
lists all modules that are needed to get the Wolfson driver running
on a stock raspbian installation - but exclude any other optional
modules that aren't strictly needed (like snd-bcm2835).

so long,

Hias

[manish-wolfsonmicro]

Hi Hias,

Don't be bothered about the dependencies .The dependency of the modules will be resolved
as per the dependency list.You will not need anything apart from this to get
the wolfson audio card and base card audio working .

~Manish

[raphaelh]

Could not get it to work either...

Manish: what is the system and versions you are using to test the Wolfson audio card?

A lot of users bought this card and very few have been able to use it, simply because of the lack of support.

If you manage to get it working on your side, please provide us with clear and detailed explanations on how we can get it to work too.

Thanks.

[gonesurfing]

I can also confirm that the list of modules provided by mannish-wolfson does not work. I have the following in my dmesg and only the onboard sound output listed in aplay. I compiled using the bcmrpi_defconfig file.

[ 12.972884] snd-rpi-wsp snd-rpi-wsp.0: ASoC: CODEC wm5102-codec not registered
[ 12.981441] snd-rpi-wsp snd-rpi-wsp.0: Failed to register card: -517
[ 12.989038] platform snd-rpi-wsp.0: Driver snd-rpi-wsp requests probe deferral

I do get the wolfson showing up using the list of modules Hiassoft provided, but get a backtrace in the dmesg. I get a backtrace if I enable the spi module in raspi-config so probably the same issue.

Edit: Testing out Hiassoft's module list, volume on recording is very low.

Edit2: Found out while Manish's list doesn't work. Seems spi-bcm2708 i2c-bcm2708 snd-soc-pcm512x snd-soc-wm8804 are all blacklisted. Once commented out, the device shows up in splay -l. Still not sure about the low volume.

[gonesurfing]

New performance issue: Did anything change with sample offset between this kernel and 3.10? I'm getting extremely poor image rejection in SDR software where the Wolfson had excellent image rejection with the old kernel. I and Q (L & R channels) must be in-phase for software defined radio to perform correctly.

Update: I found the issue causing both low volume and poor image rejection. The acceptable value ranges for IN3(L/R) and AIF1TX(1/2) both changed and the default "Record_from_lineIn.sh" from the 3.10 image was not setting the values properly.

amixer -Dhw:0 cset name='IN3L Volume' 8
is now equivalent to
amixer -Dhw:0 cset name='IN3L Volume' 72

and
amixer -Dhw:0 cset name='AIF1TX1 Input 1 Volume' 32
is now equivalent to
amixer -Dhw:0 cset name='AIF1TX1 Input 1 Volume' 64

I don't think any updates are needed to the kernel. Just a potential gotcha for those of us migrating from the 3.10 wolfson patches.

[cirrus-frankb]

The issue with the low record volume seems to have been introduced with this commit 6f2f330
In the codec driver we the ranges for "AIF1TX1 Input Volume" are defined as min 32 and max 80. This is the same in 3.10 kernel and rpi 3.12 kernel.
Before this change, when a value is set for volume it is taking as "value + min". After this change, when a value is set for volume it is taking directly as "value".

This commit only seems to be in the rpi kernel and is not in the upstream kernel.

[popcornmix]

That commit was by @hmbedded. Perhaps he can explain why we differ from upstream code.

[iqaudio]

He's onto it already - upstream has a slightly different version. Howard will respond.

Gordon

Sent from my iPhone

On 29 Oct 2014, at 12:25, popcornmix notifications@github.com wrote:

That commit was by @hmbedded. Perhaps he can explain why we differ from upstream code.

—
Reply to this email directly or view it on GitHub.

[hmbedded]

Since making the commit into the rpi kernel I submitted it upstream. It's been accepted and is now in the linux-next repo.

However, although it was accepted I had to modifiy it slightly. If you follow the link above the commit message has a good explanation of the bug that I was fixing. In the rpi kernel version I also changed the values presented to userspace so that they were the same as the values sent to the hardware. I did this in an effort to be consistent because that appeared to be the case for other mixer controls. However, when I presented it upstream the alsa devs commented that this was merely coincidence and that they would prefer not to have the userspace values changed. Therefore the upstream version only changes the values sent to the hardware (just for the invert case). So it may be that swapping to the upstream version will fix the low record volume problem.

Whether it does or not I guess it would be better to swap to the upstream version anyhow as that is what will be in future kernels. @popcornmix would you be happy to revert and apply from upstream or would you prefer me to submit a PR?

[lent]

I applied the attached patch to the current 3.12 repository, make bcmrpi_defconfig, crosscompiled, blacklisted only lirc_rpi and lirc_dev and have in /etc/modules:

spi-bcm2708
i2c-bcm2708
arizona-spi
arizona_i2c
# extcon-arizona
snd-soc-wm5102
snd-soc-pcm5102a
snd-soc-wm8804
snd-soc-rpi-wsp

yet, I get a duplicate filename for spi0.1-DCVDD and no devices on aplay -l.

Nov  1 23:13:51 quiche kernel: [    8.509721] i2c 1-004c: Driver pcm512x requests probe deferral
Nov  1 23:13:51 quiche kernel: [    8.714004] i2c 1-004d: Driver pcm512x requests probe deferral
Nov  1 23:13:51 quiche kernel: [    8.781668] MICVDD: 1700 <--> 3300 mV at 3000 mV
Nov  1 23:13:51 quiche kernel: [    8.807699] i2c 1-004c: Driver pcm512x requests probe deferral
Nov  1 23:13:51 quiche kernel: [    8.856757] MICVDD: supplied by DC_1V8
Nov  1 23:13:51 quiche kernel: [    8.913692] i2c 1-004d: Driver pcm512x requests probe deferral
Nov  1 23:13:51 quiche kernel: [    8.975882] ------------[ cut here ]------------
Nov  1 23:13:51 quiche kernel: [    8.983570] WARNING: CPU: 0 PID: 374 at fs/sysfs/dir.c:526 sysfs_add_one+0x80/0xa8()
Nov  1 23:13:51 quiche kernel: [    9.015359] sysfs: cannot create duplicate filename '/devices/platform/bcm2708_spi.0/spi_master/spi0/spi0.1/regulator/regul
ator.3/spi0.1-DCVDD'
Nov  1 23:13:51 quiche kernel: [    9.040855] Modules linked in: snd_soc_wm5102(+) snd_soc_wm_adsp snd_soc_arizona arizona_micsupp gpio_arizona arizona_ldo1 arizona_spi snd_soc_wm8804 snd_soc_tas5713 snd_soc_pcm512x snd_soc_bcm2708_i2s regmap_mmio snd_soc_core regmap_spi snd_pcm_dmaengine snd_pcm snd_page_alloc regmap_i2c snd_compress snd_seq snd_timer snd_seq_device fixed leds_gpio led_class snd spi_bcm2708 i2c_bcm2708

I don't see a big difference to the previous posts. Any idea?

[amtssp]

HI

Is this included in the new 3.17.2 kernel?
(it was present in the 3.17.1)

[cirrus-frankb]

@iqaudio Hi Gordon, Manish is no longer working on this and I'm trying to pick up where he left off so apologies in the delay in replying to your comments.
After reviewing the pull request I'm unsure of what you mean when you say "There are several parts of the i2s code which appear to be Wolfson specific" . Could you help me out and give a little more detail or point me at the lines of code that are causing you concern?
On the AVDD/DCVDD issue it looks to us as if there are a couple of things going on here. Part of the issue is to do with a dependence between our driver and the pcm512x driver so we are looking at how we can remove this dependence. There also seems to be an issue specifically with our driver which we are looking in to at the moment.

[cirrus-frankb]

@amtssp Hi, We haven't pushed this change in to the 3.17 kernel yet. The plan was to get this in to the 3.12 kernel which is what this pull request is for and then we would start to look at the issue in 3.17 and forward porting this driver. There will be some of our code in the 3.17 kernel as this will have been picked up from the mainline kernel.

[iqaudio]

I'll have to revisit this next week as we're moving this week and equipment all packed up.

Sorry.

Gordon
Sent from my iPhone

On 4 Nov 2014, at 13:28, Francis Bain notifications@github.com wrote:

@iqaudio Hi Gordon, Manish is no longer working on this and I'm trying to pick up where he left off so apologies in the delay in replying to your comments.
After reviewing the pull request I'm unsure of what you mean when you say "There are several parts of the i2s code which appear to be Wolfson specific" . Could you help me out and give a little more detail or point me at the lines of code that are causing you concern?
On the AVDD/DCVDD issue it looks to us as if there are a couple of things going on here. Part of the issue is to do with a dependence between our driver and the pcm512x driver so we are looking at how we can remove this dependence. There also seems to be an issue specifically with our driver which we are looking in to at the moment.

—
Reply to this email directly or view it on GitHub.

[gonesurfing]

About 50% of the time, the soundcard fails to be recognized on boot if I have an FTDI USB->serial device plugged in. No issues without the FTDI device. I have dmesg outputs from both. They are identical up until...

(not working output)
[ 7.588367] pcm512x 1-004d: Failed to get supply 'AVDD': -517
[ 7.595652] pcm512x 1-004d: Failed to get supplies: -517
[ 7.631720] arizona spi0.1: Failed to request DCVDD: -517
[ 7.681834] spi spi0.1: Driver arizona requests probe deferral
[ 7.689355] i2c 1-004d: Driver pcm512x requests probe deferral
[ 7.742619] pcm512x 1-004c: Failed to get supply 'AVDD': -517
[ 7.756832] pcm512x 1-004c: Failed to get supplies: -517
[ 7.763649] i2c 1-004c: Driver pcm512x requests probe deferral
[ 11.207649] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[ 11.686987] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[ 12.344604] bcm2708_rng_init=dc9fe000
[ 13.919413] snd-rpi-wsp snd-rpi-wsp.0: ASoC: CODEC wm5102-codec not registered
[ 13.928038] snd-rpi-wsp snd-rpi-wsp.0: Failed to register card: -517
[ 13.935625] platform snd-rpi-wsp.0: Driver snd-rpi-wsp requests probe deferral

(working output (long))
http://pastebin.com/i4yVwRxy

[sodabrew]

@gonesurfing Make sure you have a stable power supply with at least 750mA for the Pi, the USB device, and the Wolfson card. Get at least 1A if you have any other USB devices and if you are using the Ethernet. http://www.raspberrypi.org/help/faqs/#power

[hifiberry]

The "Failed to get supply 'AVDD'" are not a problem of the power supply. This is a pure software problem wit the 3.17 kernel. I've created a new issue for this:
#723

[popcornmix]

Is CONFIG_REGULATOR required for wolfson?
It breaks other I2S codecs (as the Pi has no regulator driver).

[HiassofT]

On Fri, Nov 14, 2014 at 11:38:25AM -0800, popcornmix wrote:

Is CONFIG_REGULATOR required for wolfson?

My guess would be yes. According to the datasheet the WM5102
used on the Wolfson card has a builtin voltage regulator and
that seems to be used. But that's just a guess, better wait
for a confirmation from Wolfson/Cirrus.

It breaks other I2S codecs (as the Pi has no regulator driver).

I'm not really familiar with the whole regulator framework, but
this looks like it might be a bug in the drivers using these codecs.

The Hifiberry Digi uses the wm8804 codec and the DAC+ uses
the pcm512x. Both codecs make use of the regulator framework,
they act as consumers and require a voltage regulator to
supply the various voltages.

If the kernel is compiled without CONFIG_REGULATOR, the
regulator functions like devm_regulator_bulk_get are replaced
by dummies and the codecs work just fine.

But if compiled with CONFIG_REGULATOR some regulators need
to be present. I'd guess that's what the "fixed" voltage regulator
should be used for. Not sure what would be the correct place
to register them, doing it in arch/arm/mach-bcm2708/bcm2708.c
like this pull request doesn't quite seem right for an off-board
regulator.

Anyone with more knowledge about the regulator framework, please
correct me if I'm wrong. I'm mainly speculating here.

so long,

Hias

[HiassofT]

I just ran into some more issues (pull request applied on top of current 3.12.y head, running raspbian):

• Playing 24bit audiofiles doesn't work, aplay fails to install hw params. For example with a 24bit stereo WAV at 44.1kHz:

  pi@raspberrypi ~/audiotest $ aplay 440hz-44100-stereo-24bit.wav
  Playing WAVE '440hz-44100-stereo-24bit.wav' : Signed 24 bit Little Endian in 3bytes, Rate 44100 Hz, Stereo
  aplay: set_params:1145: Unable to install hw params:
  ACCESS:  RW_INTERLEAVED
  FORMAT:  S24_3LE
  SUBFORMAT:  STD
  SAMPLE_BITS: 24
  FRAME_BITS: 48
  CHANNELS: 2
  RATE: 44100
  PERIOD_TIME: (125011 125012)
  PERIOD_SIZE: 5513
  PERIOD_BYTES: 33078
  PERIODS: 4
  BUFFER_TIME: (500045 500046)
  BUFFER_SIZE: 22052
  BUFFER_BYTES: 132312
  TICK_TIME: 0
  

  The same happens for other sampling rates (tested with 8kHz-44.1kHz)

• 16kHz audio files sometimes play back in the wrong pitch. I can reproduce this with the following steps:

  • power up pi
  • play a 44.1kHz stereo 16bit WAV (plays fine)
  • play a 16kHz stereo 16bit WAV (pitch is too high)

  Playing the 16kHz file immediately after power up seems to be fine, though.

For my tests I used Audacity to create 16bit stereo WAVs with a 440Hz sine test tone at various sampling rates (8000-44100Hz). Then I used sox to convert these files to 24bit WAVs (sox in.wav -b 24 out.wav).

[gonesurfing]

I'm still having issues with the card not being detected. I have not updated the kernel since my original build of this pull request, yet connectivity issues are getting worse. I've replaced the power supply with no help. Unplugged all usb attachments during boot with no help. Since the standoff holes don't line up properly, they were putting some stress on the pogo pins but fixing this didn't help. It will take 4-5 boots for the card to be detected most of the time now. I moved the sd card and sound card to a brand new model b pi and had the same issue. I've eliminated everything but A) Bad card B) Some race condition where the card is not detected due to other things happening.

Dmesg output looks similar to the ones I posted above.

[gonesurfing]

I'm still struggling with card not being detected. I blew away any non-standard scripts I had at start-up and it seemed to help. There was one perl script that pinged the serial port, but this was run at runlevel 2 so it shouldn't have affected anything during boot (I don't think). I then rebooted about 6-7 times and every single time the card was detected. Victory! This evening I cycled power to it (forgot to halt), and then on boot you guessed it... aplay -l shows "no soundcard detected". 4 reboots later, it mysteriously appears again with absolutely no intervention on my part.

There is definitely a timing issue at boot on my pi (and the new one i tried).

Is anyone still working on this pull request at Wolfson? The comments seem to be getting thin again.

[sodabrew]

@wm-frankb The RPi A+ / B+ model is now available. Will this driver require any changes to support the new board?
http://www.mcmelectronics.com/product/83-16518

[syberphunk]

@sodabrew The wolfson audio card is not supported on the A+/B+ , you would have to purchase the Cirrus Logic Audio Card http://www.mcmelectronics.com/product/MCM-2448312-/83-16518

[sodabrew]

@syberphunk The RPi A+ / B+ model is now available. Will this driver require any changes to support the new board? http://www.mcmelectronics.com/product/83-16518

[syberphunk]

@sodabrew I would imagine so, yes.

[popcornmix]

Closing as Manish is no longer working on this.
There should be a new device tree enabled driver submitted by Cirrus soon.