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?

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

Hias,

Many thanks.  Here is a link https://www.dropbox.com/s/q5syxn3asr2yirq/WISCESetup.zip?dl=0 to the WISCE I use, without any problems. Cannot help with the error, I have never seen it. I have noted that WISCE does a lot of parameter checking.  Is it posssible that you have some DSP microcode loaded (or are trying to load) that WISCE does not like? (Which is to say that WISCE is working perfectly, it is just that it doesnt like DSP code).  As I understand it, none of us are using/loading the DSP. 

I have been digging around this evening looking for an alternative to WISCEBridge for connecting to the 5102 from WISCE (which would be ideal since there is WISCEbridge for linux)  ..... WISCE will allow a direct i2c/spi connection to the 5102 via an Aardvark USB interface  ...... which has the same pinout as the USBi/ freeUSBi   ...... so it is JUST possible that the freeUSBi interface will allow a USB -> i2c/spi connection from WISCE to the 5102  .... but of course there are bus master problems if the pi is connected as well

I have been using i2c-tools to write to the 5102 directly  .... and it took a while to find out that nothing worked except when playing some music!  It is buried away in the 5102 documentation  .... the device will respond to SPI and/or I2C when being clocked, but only the original bus used at boot time if the device is "stopped". So your explanation that you use spi at boot fits well :- except that I am confused! My reading of the Wolfson circuit schematic suggests that there is only an i2c connection to the 8804, so I added a couple of wires to link in the 5102  ... but that does not fit with what you say, unless of course you added two link wires as well.

I'll look at cirrus-reg.c .... I am sure that it will be easier that using i2cwrite/read! (Postscript:- yes that will make life simpler, thanks)

And the Wolfson documentation is invaluable for working out how to program the 400 odd registers for the four EQ!!  At the moment I am not optimistic about getting good low frequency equalisation

Best Wishes

John

Hi John!

Many thanks. Here is a link https://www.dropbox.com/s/q5syxn3asr2yirq/WISCESetup.zip?dl=0 to the WISCE I use, without any problems. Cannot help with the error, I have never seen it. I have noted that WISCE does a lot of parameter checking. Is it posssible that you have some DSP microcode loaded (or are trying to load) that WISCE does not like? (Which is to say that WISCE is working perfectly, it is just that it doesnt like DSP code). As I understand it, none of us are using/loading the DSP.

Thanks for the link, but I didn't have much luck with this version either. Here's what I did:

• start up my WindowsXP virtualbox VM
• uninstall previous WISCE version and WM5102 setup
• install your WISCE, using default settings (I even let it install the FTDI drivers)
• in WISCE click on "Add System" and choose "Create a new simulated system"
• Add device dialog pops up, only selectable chip is WM5102 Rev C, I accept the default settings (SMBUS, address 0x34)
• After a few seconds a dialog pops up with the message "Failure adding device 'WM5102'. Please contact WISCESupport@cirrus.com with the details of the device you were trying to use"

Then I checked the logfile, found this at the end of it:

06-04-2017 10:23:52.369 * Detecting devices for Simulated system.
06-04-2017 10:23:52.369 *    - No devices detected.
06-04-2017 10:25:22.178 *    - fully loaded c:\programme\wolfson evaluation software\devices\wm5102_regmap_revc 2v9.wxd
06-04-2017 10:25:23.340 * Internal Error - WARNING: Firmware on WM5102's DSP1 core is NOT valid.
06-04-2017 10:25:23.570 * Internal Error - Failure adding device entity for region 'WM5102': System.IO.FileLoadException: Eine von "Wolfson.WISCE.Filters.dll" importierte Prozedur konnte nicht geladen werden.
Dateiname: "Wolfson.WISCE.Filters.dll"
   bei System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous)
   bei System.Windows.Forms.Control.Invoke(Delegate method, Object[] args)
   bei System.Windows.Forms.WindowsFormsSynchronizationContext.Send(SendOrPostCallback d, Object state)
   bei Wolfson.WISCE.Entities.DeviceEntity.Initialize(IDataRegion region)
   bei Wolfson.WISCE.Entities.DeviceEntity..ctor(SystemEntity system, IDataRegion dataRegion, String deviceName)
   bei Wolfson.WISCE.Entities.DeviceEntity.Create(SystemEntity system, IDataRegion dataRegion)
   bei Wolfson.WISCE.Entities.SystemEntity.GDNNINCJKLLEILDPMMHMEAAEBPCLDIJFCBAH(IDataRegion  )


06-04-2017 10:25:23.570 * Error - Failure adding device 'WM5102'. Please contact 'WISCESupport@cirrus.com' with details of the device you were trying to use.
06-04-2017 10:27:14.810 * --------------------Closing WISCE™--------------------

Not quite sure what's going wrong there, the DSP firmware warning could be a red herring and the real issue some dll/system incompatibility. I guess I'll leave it there.

I have been using i2c-tools to write to the 5102 directly .... and it took a while to find out that nothing worked except when playing some music! It is buried away in the 5102 documentation .... the device will respond to SPI and/or I2C when being clocked, but only the original bus used at boot time if the device is "stopped". So your explanation that you use spi at boot fits well :- except that I am confused! My reading of the Wolfson circuit schematic suggests that there is only an i2c connection to the 8804, so I added a couple of wires to link in the 5102 ... but that does not fit with what you say, unless of course you added two link wires as well.

Just checked the schematics, on the Cirrus card I2C of the WM5102 is connected to RPi as well, but on the original Wolfson card the I2C interface of the WM5102 seems only to be routed to the ext connector. See page 3 of the schematic PDFs, CIF1SCLK and CIF1SDA signals.

I did most tests with the Cirrus card so that explains why I didn't have to modify anything

BTW: Why are you trying to access the WM5102 directly? The majority of the WM5102 registers are exposed via alsa controls and if you access the chip directly the register contents of the WM5102 will be out of sync with the (cached) register settings used by ASoC/Linux - check /sys/kernel/debug/regmap/spi0.1/registers for example. This can quickly lead to a mess, so be very careful with that. Better stick to the alsa controls and only use direct access for registers that are not exposed via alsa.

so long,

Hias

Hias,

Well on the WISCE software, perhaps it is the 5102 exe file that is the problem ..... so just in case  ....  https://www.dropbox.com/s/lwokz6h2bn81pvt/WM5102Setup_Rev2_9.zip?dl=0  > It seems quite possible, since the problem only occurs when you load the device.  I have also uploaded the 8804 specific file  https://www.dropbox.com/s/sen92d6zv2mazss/WM8804Setup_Rev1_1.zip?dl=0   , that way you can try starting WISCE without loading the 5102 information.

On the I2C, I did wonder whether that was the explanation

As to direct writes, you are of course right  ..... it is just that repeatedly typing 80 quasi random hex charecters is pretty error prone when I want to change one byte (well strictly 2 bytes).  I guess I could write a script, but I might end up spending more time on the temporary fix than on the experiment.  The purpose of my earlier email was to find out what way you thought best  ..... and I will happily follow your advice.  Any final system, I will use the alsa set/get  .... but like you I need a quick debug route to find out whether I can get low frequency (less than 500hz) filtering working to my needs before investing lots of time on scripts (in which I am not particularly well experienced.  My plan is to use php to serve up pages of possible settings and receive user adjustments.  Have some basic stuff working, but have not tried the complex maths that is going to be needed to convert.  By the way, is there an easy way to determine current sample rate through an alsa call to the driver, because this will be set by MPD autonomously and it is a key number in filter calculations)

Cheers

John

Hias,

Bad form replying to my own post, but I have started playing with the EQ filter parameters, guided by WISCE.  herewith some results

The curves here are not particularly important. what is important is that WISCE only allows certain, heavily quantised frequencies, all of them above 100Hz.  The purple curve might give a clue why,  I think that (for obvious reasons) it is seeking to have zero gain at 0Hz.  Well that is all sensible, but when I try to "ski off piste" by putting raw values into amixer set commands (nothing extreme, just shifting the frequencies slightly) the linux driver throws me out with an "invalid parameter" warning. So not only WISCE , but ALSA as well are doing parameter checking.  So in answer to your earlier question, it would seem the only way to use other parameters is by direct register access via i2c   ....... accepting of course the risks involved!

(Postscript:  any idea where the parameter checking is done?    ...... .with a bit of generous help from A.N.Other it is done in arizona.c  . which fails all A and B parameters whose absolute value exceeds 4095 and also does a ratio check between A and B)

John

Hi John!

Thanks a lot for the WM5102/8804 setup files, but I did get the same error(s) as before. When using the WM8804 I also got the DLL error - which seems to be the root cause for both WM5102 and WM8804 failing. I'll leave it there, no interest in entering the windows DLL rabbit hole (after all it could be caused by using Windows XP).

As for the filter coefficients: the wm5102 driver has been written by Wolfson/Cirrus so I'd guess they put the checks in there for a reason

The datasheet indicates that the allowed filter cuefficients depend on sysclk which is either ~49MHz (when using 32/48/... kHz) or ~45MHz (at 44.1/88.4/... kHz) - so the actual samplerate shouldn't have be a huge issue. Anyways, you can check the current audio device playback settings via /proc/asound/card0/pcm0p/sub0/hw_params (or pcm0c for capture/recording).

so long,

Hias

All,

OK, to close off my thinking on the equalisation blocks.  Finding the parameter checking in the driver (the bit provided by Wolfson in arizona.c) has revealed a lot about the parameters you should pass to the equalisation blocks in the Wolfson.

The checking is exactly that needed to check for stability in second order biquad filters and corresponds perfectly with the checking done by the WISCE software.

No big suprises there.

But what that means is that if the WISCE software will not let you have a certain set of parameters, it is for good reason and no amount of bit tinkering elsewhere will give you extra functionality from the WM5102.  Worse, you will have unstable filters.  I have for example verified that (at 44100) the first three frequency bands you can have are 110 156 and 191Hz.  Not only does this show from the WISCE software, it corresponds exactly with the quantisation of the a1, a2 parameters in a biquad filter  ...... 1+a1+a2= 1/4096,2/4096,3/4096 (read www.st.com/resource/en/application_note/cd00222512.pdf if you want.  It is the least mathematical explanation I can find, and predicts perfectly filter frequencies)

So what does all that mean.  Basically that you cannot have accurate low frequency band pass /cut filters with the Wolfson. I would suggest that the accuracy becomes sufficiently good at 300Hz and above for 44100 data( the first 10 bands are 110, 156, 191, 221, 247, 270, 292, 312, 331, 349 HZ, shifting a bit depending on Q).  And the situation is in reality worse for higher sampling rates (the band frequencies are those I have mentioned multiplied by the ratio of the sample rates, so at 88.2 the bands are at twice the frequency) .

So the EQ units can be used effectively as tone controls but not as an effective DRC (digital room correction) for the sized rooms I live in. The Low/High pass filters are much more useful with set points only 2-3Hz apart.

I guess that is already more than enough, but if anybody needs further details, I am happy to provide.

(postscript .... and the parameter for the low/high pass filters on the Wolfson follows perfectly the same maths, that is to say (quoting the above source)

First-order filter design

As a first step to obtain the coefficients for the 1st-order low-pass or high-pass filter the following equations can be used:

     θ C = 2 ∗ π ∗ f C / f S (= the normalized cut-off frequency)

     K = tan(θ C / 2)

     α = 1 + K.

The denominator coefficients are identical for both low-pass and high-pass filters designed for the same cut-off frequency and are computed as follows:

a1 = -(1 - K) / α =-(1-K)/(1+K)

All you need to do to generate the the Wolfson parameter is multiply a1 by 4096 and make the result 16 bit signed

All,

OK, to close off my thinking on the equalisation blocks.  Finding the parameter checking in the driver (the bit provided by Wolfson in arizona.c) has revealed a lot about the parameters you should pass to the equalisation blocks in the Wolfson.

The checking is exactly that needed to check for stability in second order biquad filters and corresponds perfectly with the checking done by the WISCE software.

No big suprises there.

But what that means is that if the WISCE software will not let you have a certain set of parameters, it is for good reason and no amount of bit tinkering elsewhere will give you extra functionality from the WM5102.  Worse, you will have unstable filters.  I have for example verified that (at 44100) the first three frequency bands you can have are 110 156 and 191Hz.  Not only does this show from the WISCE software, it corresponds exactly with the quantisation of the a1, a2 parameters in a biquad filter  ...... 1+a1+a2= 1/4096,2/4096,3/4096 (read www.st.com/resource/en/application_note/cd00222512.pdf if you want.  It is the least mathematical explanation I can find, and predicts perfectly filter frequencies)

So what does all that mean.  Basically that you cannot have accurate low frequency band pass /cut filters with the Wolfson. I would suggest that the accuracy becomes sufficiently good at 300Hz and above for 44100 data( the first 10 bands are 110, 156, 191, 221, 247, 270, 292, 312, 331, 349 HZ, shifting a bit depending on Q).  And the situation is in reality worse for higher sampling rates (the band frequencies are those I have mentioned multiplied by the ratio of the sample rates, so at 88.2 the bands are at twice the frequency) .

So the EQ units can be used effectively as tone controls but not as an effective DRC (digital room correction) for the sized rooms I live in. The Low/High pass filters are much more useful with set points only 2-3Hz apart.

I guess that is already more than enough, but if anybody needs further details, I am happy to provide.

(postscript .... and the parameter for the low/high pass filters on the Wolfson follows perfectly the same maths, that is to say (quoting the above source)

First-order filter design

As a first step to obtain the coefficients for the 1st-order low-pass or high-pass filter the following equations can be used:

     θ C = 2 ∗ π ∗ f C / f S (= the normalized cut-off frequency)

     K = tan(θ C / 2)

     α = 1 + K.

The denominator coefficients are identical for both low-pass and high-pass filters designed for the same cut-off frequency and are computed as follows:

a1 = -(1 - K) / α =-(1-K)/(1+K)

All you need to do to generate the the Wolfson parameter is multiply a1 by 4096 and make the result 16 bit signed

I have now managed to decipher the 5102 parameters for EQ and LHPF .  I hesitate to share here, but if somebody needs a steer

Hi John!

I have now managed to decipher the 5102 parameters for EQ and LHPF . I hesitate to share here, but if somebody needs a steer

Awesome, please post details, this sounds very interesting!

As for the firmware files:

wm_adsp will automatically try to load the firmware file(s) if a signal path is running through the DSP. eg configure headphone out to run through the DSP:

amixer -q -c RPiCirrus cset name="DSP1L Input 1 AIF1RX1"
amixer -q -c RPiCirrus cset name="DSP1R Input 1 AIF1RX2"
amixer -q -c RPiCirrus cset name="DSP1L Input 1 Volume 32"
amixer -q -c RPiCirrus cset name="DSP1R Input 1 Volume 32"
amixer -q -c RPiCirrus cset name="HPOUT1L Input 1 DSP1.1"
amixer -q -c RPiCirrus cset name="HPOUT1R Input 1 DSP1.2"
amixer -q -c RPiCirrus cset name="HPOUT1L Input 1 Volume 32"
amixer -q -c RPiCirrus cset name="HPOUT1R Input 1 Volume 32"
amixer -q -c RPiCirrus cset name="HPOUT1 Digital Volume 128"
amixer -q -c RPiCirrus cset name="HPOUT1 Digital Switch on"

Then playback a file and watch dmesg for the "firmware not found" error message

You can configure the name of the firmware file with the "DSP1 Firmware" control - it lists 11 choices.

I never tried this, not sure where to get the firmware files (there probably are some sample firmwares around). If you got one, put it in /lib/firmware, then it should get loaded.

IIRC the DSP development software is a commercial product and rather expensive - there was some talk about it a few years ago on the other (Wolfson audio card) forum. Not sure if you are able to get it without paying bick bucks and signing NDAs or such stuff.

Concerning WISCE: I finally got it running, had to setup a Win7 VM though. I tested shortly with wine (actually that was the first thing I tried, before using the WinXP VM) but didn't have much luck either.

so long,

Hias

Hi Hias,

Here is the maths I have worked through.  There are many variants of the maths to describe bi quad filters.  I tried several others, but this one is the simplest I have found for the Wolfson.

With the exception of the band pass elements, all the parameters are an exact fit to the WISCE provided parameters.

For the pass band elements, parameters A and B are again exact matches to the WISCE provided values.  These two parameters define frequency and bandwidth.  The remaining two parameters, B and PG (=pre gain) are not exact matches to WISCE provided numbers but experimentation shows that these parameters change little and that which I have provided are close.  In particular, a little more work on PG should get an exact value .... note the similarity between the PG used for Band 1 (which is an exact match) and the empirical PG used in the biquad.

AS to firmware files, you might want to visit

https://github.com/lenovo-yt2-dev/proprietary_vendor_lenovo_YT2/tree/cm-12.1/proprietary/etc/firmware

But sadly, yes, I doubt we will ever get details about the ADSP2 core, so programming to my needs is out  ...... it will have to be brutefir  ..... which is pretty good stuff, I just wanted to unbundle all the audio processing onto the wolfson.

John,

Reading your posts I must admit my knowledge of filtering is not near your expertise.

Stil I would like to ask you a question for possible use in the Cirrus Logic Audio Card.

Currently I experiment/use the card to drive my speakers using the on board amplifier.

Although rated at 1.4 to 2.8 watts in different documents I am impressed to what volume it produces with my speakers.

It is enough for serious listening in house in my situation.

Still as the speakers can be bi-amped , I was wondering if it would be possible to use the 2 channels to drive the low, and mid+high speaker separately and  gain a bit more efficiency by digitally filtering signals before amplifying them, and avoid losses in the speakerfilters.

As the wolfson chips only have 1 stereo path I seen no output for a separate (sub) woofer output, not even if it is un-amplified signal for an external amp.

But correct me if I am wrong.

Do you see options to set separate low pass and high-pass filters to drive high and low drivers separately  ?

And would it really output more efficient energy to the drivers to be noticeable ?

If you could help me set filters around 400 Hz, I would like to try it .

And as I have 2 cirrus cards I could use all 4 amp channels.

Regards Marcel

Hi Marcel,

If I have understood your questions correctly the answer is yes to almost all of them!

Perhaps if I explain the setup I actually use at home when listening to music it will give you a way of doing what you are seeking to do.  (Before I do I should explain that, if I remember the datasheet correctly, all 3 of the outputs from the 5102 are electrically equivalent, which is to say they can all drive 15 ohm loads)

I have two speakers connected to a nice 1980s amplifier.  I also have an active sub-woofer.  The amplifier (and indirectly the speakers) is connected to the line out socket of the Wolfson.  The sub-woofer is connected to the headphone socket.  So one Wolfson card feeds 3 channels, it could do more.

Now my sub-woofer has a built in low pass filter.  So all I need to do to get that to work is to connect both L and R channels from the input to the left (or right) mixer of the headphone ouput. That mixes stereo down to mono for the sub-bass output.

For the main speakers obviously L and R are kept apart.  For each of the two channels the input goes to a LHPF block, then to a second LHPF block and finally to the line output.  This gives a very sharp cut-off and in this case the LHPFs are programmed as high-pass filters which are the complement of the (analogue) low pass filter built into the sub-woofer.  You could use just one LHPF block on each channel and have a softer roll-off.  This would be necessary if you need to put a low pass filter into the sub bass outputs. (Because the digitial core of the 5102 has just 4 LHPF modules)

All of the connections and filter settings are programmed through Alsamixer, thanks to Hias excellent work.  Elsewhere in this thread I have described how to calculate the filter parameters, though a simpler way of doing it is to use the WISCE software to calculate the numbers.

400Hz seems very high for a cross over frequency, is that what you need.  And do you know how rapid the roll-off needs to be?  If I understand correctly you want to low pass one pair(L/R)  of outputs and high pass the other pair.  Off-hand (though it is late) I cannot think of a simple way of passing the settings you require.

So there are some challenges in the detail,  but I believe that all you want to do can be done, by a single 5102 board

John

Hi John,

I have done no calculations on my speakers, and also do not know where to get the data to do them.

The column speakers do have quite some volume ( in liters ) but the low drivers are not as big as a separate ( active ) subwoofer would have.

For the about 16 CM drivers I just guessed 400 Hz as a first attempt.

And with very steep filtering handover is more pronounced and thus easy to noticed if not set correct.

I understand your setup where you use line out and headset out to carry the same stereo signal, but filter them differently, and in combination with your external subwoofer speaker filter and mono , add combine this into 1 low signal that is amplified in that box.

My idea was to use the 2 channels  in 1 card to both carry , f.i. the left channel.

And then filter 1 to pass high, feed it to the on-board amplifier and feed the mid/high section of my speaker.

And let the other to pass low , feed it to the on-board amplifier 2 and feed the low section of my speaker.

This woud reduce my output to just the left channel, but with a separate amp for low and mid/high.

If I remember correctly from playing with the alsa options the filters for left and right are separate, and routing of 1 signal channel in both output channels is possible.

The experiment would be to see if one could obtain more effective output by filtering before amplification , and secondly if it would produce a noticeable result.

.....

Thinking of it a bit more now, using a second pi and card to drive the other channel would generate time differences in left/right channel reproduction and create distortion in the stereo image. And this is likely to be much more a disadvantage than the gain one could obtain from a bit more power.

So if I would choose Mono output, the idea might be useful, but for stereo external amps are required to get a bit more output power.

Regards, Marcel

Those on  chip D class amplifiers are remarkable for what they do, but personally I would not use them.  You could arrange to use that amplifier for just the high frequency components where less power is needed (above 1kHz). That would still lead to you needing a stereo amp for the LF though.  I am fairly sure that some Lenevo tablets use the 5102 power amp to drive their speakers, so that gives an idea of where they do well.

I am not sure whether you picked up on my observation that both the line out and headphone out are capable of driving 15 ohm loads (though I repeat I would not do it).  So conceptually you could have Left channel feeding two filters (one high pass, one low pass) and these two signals feeding the headphones out.  The Right channel could follow the same logic except it could feed the line out socket.

However I presume you are using speaker out to drive your speaker, which is capable of driving 3 ohm loads. And there you have just two channels ...

  There are so rediculously cheap small class d amps out there eg

PAM8403 Ultra Miniature Digital Power Amplifier Board Class D 2channels x 3W 8′′ | eBay

at 0,30 euros.

I would use a couple of those and protect my precious Wolfson!

As to connecting two Wolfsons/Pi together, I wouldnt.  unifying the two I2S clocks represents a huge effort

Thanks John,

Indeed I did not notice enough the line out  AND  headphones out both can carry the same signals with their own individual filters.

Combined with external amps one could indeed build a setup for bi-amped speakers.

I definitely want to experiment with that in combination with a multi channel amp I already own, it would just need 4 analogue  inputs to be active to 4 amp outputs.

If combined with speakers out one could do a how-mid-high separation but that is fun in theory only I presume.

On the D-amps indeed they do perform much better than people do credit them for.

My experiments with the PAM 8403 boards are positive, but I prefer the on-board amp in the cirrus logic audio card.

I really do recommend you test them once. Depending on the the effectiveness of your speakers it does create enough signal to enjoy your music.

Combined with the digital silence of the card , it is ideal for a bed side audioset to wake you up in the morning , without the sound of the sea during the night.

In need to do more reading on the amp used in the card....

Edit :.As the 5102 you mentioned is rated at 2*20 Watt max and should not be fed with less than 8 volts.....

Edit : confused the wolfson 5102 chip with an other popular chipmakers 5102.

Edit :  2 watt D-amps according to chip datasheet

Regards Marcel.

Hi John,

I believe that there is a way that you can program the ADSP2 to your desires.

The tools for creating your own DSP software are available from Cirrus Logic (WISCE), and the compiler is from Synopsis (Target Compiler Technologies) (Chess Development Environment).

Depending upon which specific DSP (Smart Codec) you have from Cirrus, you may be able to obtain a development board for your specific needs and experiment with your own code development on the DSP and implement all the fancy processing you desire.

There is a learning curve, but once you get over the early part, you will be up and running.

Best regards,

David

David,

Many thanks for this tip.  I have used the WISCE software quite extensively.  It provides a means of setting parameters in the "static" part of the digital core and also (if I remember correctly) uploading soft/firmware into the 5102, but does not, as far as I am aware, allow development of the DSP code.  So your tip for Synopsis is useful, and I will follow it up.  Wolfson (who were brought out by Cirrus) called there DSP core the ADSP2, but there are several clues that it is a brought in design   ...... but exactly which is less clear!

The main clues in the 5102 manual are

Program memory      10_0000h to 10_5FFFh (24576 registers)      8192 x 40-bit words

Coefficient memory      18_0000h to 18_07FFh (2048 registers)      1024 x 24-bit words

X Data memory           19_0000h to 19_47FFh (18432 registers)      9216 x 24-bit words

Y Data memory           1A_8000h to 1A_97FFh (6144 registers)      3072 x 24-bit words

So the data memories correspond to the ADC and DAC width (but I guess the core will run at higher precision to allow multiply etc)

Just noticed there is a JTAG interface to the core, but whether I have the time to hack ....

I also have some stock firmware images for the 5102 DSP, which might also provide clues as to whether I am on the right track. 

If I make progress I will report back here, but my life is pretty busy at the moment, so it may not be very soon.

Regardless, thanks again  .... the prospect of developing a FIR filter still appeals to me