Thanks for the reply.
Regarding the noise I described, it's most noticeable soon after starting the Pi+CLAC, then after a while becomes less audible. It seems to be crosstalk from the Pi to the output stages of the CLAC, but I haven't yet ascertained whether it is conducted through the power rails, or radiated.
I use the official Pi PSU, but intend to try Andrew Weekes filter idea soon - this could help if the power lines are bringing noise from the Pi to the sound card.
Thanks for the driver!
I followed the instructions on your site, but I still do not see the audio card in the list:
**** List of CAPTURE Hardware Devices ****
card 1: Device [USB Audio Device], device 0: USB Audio [USB Audio]
Subdevice #0: subdevice #0
I am using a Rpi 3 with version 4.14:
I have attached a file with my config file etc.
Any help would be appreciated!
Thanks a lot
logoutputs.txt.zip 11.2 KB
I'm not Matthias, but perhaps I can help. My first question would be "what hardware modifications have you made", ie how have you connected the Wolfson card (presuming that you do not have one of the Cirrus cards with the 40 way connector). Many/most of us have made minor errors in the connection
Ah, just looked at your (useful) log file ..........I note mention of NOOBS in your config.txt file ..... what is the origin of your kernel ?
1 of 1 people found this helpful
These 2 lines suggest the card is not plugged in correctly (or something is severely broken):
[ 16.942194] wm8804 1-003b: Failed to read device ID: -121 [ 16.942652] wm8804: probe of 1-003b failed with error -121
The wm8804 should always be detected and log a line like this:
[ 11.793763] wm8804 1-003b: revision E
Also this line suggests you could have missed to add a /etc/modprobe.d/cirrus.conf file with "softdep arizona-spi pre: arizona-ldo1"
[ 16.896407] arizona spi0.1: Failed to request DCVDD: -517
Thanks a lot. I'll check it.
My card is now attached but is still giving the above errors.
I notice it is a WM8974 AND NOT A WM8804.
Is this supported?
I notice it is a WM8974 AND NOT A WM8804.
Is this supported?
No - it seems you are using an entirely different card. These threads are about the Wolfson Audio Card (which looks like this: https://files1.element14.com/community/themes/images/wolfson/piaudiocardoct21.gif ) and the Cirrus Logic Audio Card (which looks like this: https://files1.element14.com/community/themes/images/cirrus/cirrusAudiocard.jpg )
You'll have to check with the manufacturer of your card for instructions on how to set it up or troubleshoot issues.
If anyone has a go at building the Touschscreen Pi music player I built here, I've designed a replacement rear cover for the Pi Hut case I used that can be fitted when the Wolfson card is installed.
It's my first bit of 3D CAD, so I used Tinkercad and a work colleague printed it for me on a very inexpensive printer. It's not perfect, but it's pretty good!
Hi all !
For quite a long time now (sort of... let's say months) I've been working on a PI+this soundcard-based electronic drum sound synthesizer. It works quite well, but now I'm working on making hit-to-sound latency as low as possible. A measure I performed last week showed there is a MIDI-to-sound-activity latency of 6 to 9 ms.
I know that I cannot reduce nor the hit-to-MIDI latency (done by the sound module of my drum kit), neither the MIDI transport delay (3 bytes at 31250 bps, about 1 ms).
I use ALSA to connect to system sound stream, and I could not get better settings than a period of 64 frames with a buffer size of 2 periods (i.e. 128 frames). At 44100Hz, it makes an extra (software) latency of 2.9 ms.
What i'd like to know is :
- is there a way to force ALSA to accept shorter period ? It might be related to hardware limitations but I don't know.
- is there a way to address the card without ALSA (so I think no other process could access the sound card) ?
- Is there a way to have a direct access to I2S component of the SoC ?
- Any other way to reduce this SW latency ?
The minimum period size comes from the generic dmaengine driver - it's set to 256 bytes here: https://github.com/raspberrypi/linux/blob/rpi-4.14.y/sound/soc/soc-generic-dmaengine-pcm.c#L144
You could try patching the file to use a lower value and see if it works.
Another options are to use 24 or 32bit format instead of 16bit - 256 bytes then correspond to 32 frames - or to use higher sample rates - 64/32 frames then correspond to shorter time periods.
With very short buffers there's an increased risk of over/underruns due to scheduling, interrupt, ... latencies. If you are experiencing these issue testing a kernel with realtime patches could be worth a try. A RPi 4.14 kernel with -rt patches is available from the official RPi kernel git https://github.com/raspberrypi/linux/tree/rpi-4.14.y-rt but keep in mind that this is rather experimental stuff. I haven't used the current -rt kernels myself yet on RPi, so don't know how usable these kernels are.
Switching to 32bits samples is a smart idea ! It's indeed supported and leads to a latency twice as less as with 16bits samples ! Thanks.
Increasing sample rate is a good idea too, but I fear the CPU will not be powerful enough as I use a time consuming reverb effect. And I would have to resample all my sound samples.
I'm now trying to rebuilding kernel... but the soundcard is not detected. I've already successfully done it before with older kernels but this time it does not work... still trying.
note : with rpi-update, I can use the soundcard I usual, but not with rebuilt kernel.
I finally managed to compile linux kernel with de modification you suggested in soc-generic-dmaengine.c. I changed min bytes to 64 instead of 256. The best sustainable sound buffer configuration I could get is :
samples : 16bits
period : 32 frames
buffer size : 3*period (96 frames)
Which leads to a theoretical latency of 2.17 ms.
Measured MIDI-to-sound-activity latency is 5 to 7ms. Not outstanding but better.
Note 1 : I had to locally build linux kernel, as cross-compiling led to soundcard detection error ...
Note 2 : Durig my tests, I noticed that using a too short buffer (either too short period or too few periods in buffer) crashed something in the sound path (Alsa ? Driver ? Soundcard itself ? other ?). A reboot was required to be able to use the soundcard again.
I will now test other configurations, just to be sure, and let you know.
Thanks for your help.
I have on problem..., i have all made like tutorials said
(raspberry 3, raspbian 4.14, lcd touchscreen (no hdmi connected so))
sudo rpi-update is done (with firmware suppression before)
give me :
amixer: Control hw0: open error: Invalid argument
(many times the same line, repeated again and again)
give me :
aplay: device list:277: control open (0): invalid argument
I was setup before with 4.4, and during my C++ test, all worked perfectly, playing with sine waves.... and without knowing why, sound stopped... and the aplay -l command has stop working...
So i try :
sudo tar zxf ../cirrus-ng-linux-4.9.4.tgz -C /
sudo nano /boot/config.txt
i learn :
[ 3.913997] snd-rpi-cirrus soc:sound: ASoC: CODEC DAI wm5102-aif1 not registered
[ 3.924215] snd-rpi-cirrus soc:sound: ASoC: CODEC DAI wm5102-aif1 not registered
But all that didn't help me, so... please help !! I spend all the day and the night on this, and i still can't find why nor a solution ...
Thankyou very much for any help !
Please don't use the ancient 4.9 kernel, it's heavily outdated. The driver has been included in official RPi/Raspbian kernels for well over a year now.
Please remove all custom configurations (like blacklisting the raspberrypi-kernel package in Raspbian etc), use a unmodified Raspbian installation and follow the configuration steps from here RPi Linux driver for Wolfson / Cirrus Logic Audio Card
I already have try these configuration steps, and i have just retry, but unfortunatly nothing change, always the same problem.
I have removed the customs lines, and re-enabled the onbord card, just to see if it's detected : aplay -l still don't work... (aplay: device list:277: control open (0): invalid argument)
Sorry, i'm only good under windows, but not under a linux environnement...
Should i format and reinstall a new raspbian to make it work again ? :-(
And for my knowledge, why my sound card just stop working, i have nothing asked, no started update, no open terminal, just working as remoteGDB from visual strudio. I have already should reinstall all because it has stopped working, one year ago. I did not asked for that.
So i suppose that silent updates are done, is that right ?
I've been working on a driver rework, mainly to get rid of the requirement to carry around a bunch of patches to upstream driver code, and also to fix some outstanding issues and introduce some new features.
Most issues have been ironed out so here's the first public release.
Edit: the driver has been included in official RPi kernels. Just run sudo rpi-update to install it.
You still have to install the mixer scripts and add the /etc/modprobe.d file. See my website for details
Precompiled kernel: http://www.horus.com/~hias/tmp/cirrus/cirrus-ng-linux-4.9.0.tgz
New mixer scripts: http://www.horus.com/~hias/tmp/cirrus/cirrus-ng-scripts.tgz
- The new driver bases on the rather fresh kernel 4.9.0 which means there's some risk of (yet unknown) issues. Use it at your own risk and please run "rpi-update" to get the latest firmware before installing the new driver.
- The soundcard name has been changed from "snd_rpi_wsp" to "RPi-Cirrus", also several ALSA controls have been removed and new ones were added. This means the old usecase scripts and any custom-made scripts will no longer work. Use the new mixer scripts instead of the old usecase/listen scripts.
- The new driver supports setting (and receiving) of the S/PDIF channel status bits (aka AES bits). If you add an ALSA card configuration file this means applications like Kodi can do proper AC3/DTS passthrough. A sample card configuration file (plus the mixer scripts) can be found here: https://github.com/HiassofT/rpi-cirrus-config
- I haven't fully updated the documentation on my website RPi Linux driver for Wolfson / Cirrus Logic Audio Card yet, will do that during the next weeks/months. But except for the things noted above most stuff should still work as in previous driver versions.
Please report back if you tested the driver (either successfully or unsuccessfully), any feedback will help me!