I have a stock Pi 3B with all Raspbian updates. From various sources I've tried to cobble together alsa recording from an inexpensive PCM1808 device at 8K 24 bit stereo. To do this, I've used the pigpiod daemon to provide the SCK for the chip at 2048000 Hz (pigs hc 4 2048000). The 3 outputs from the chip in master mode BCK, LRC and DOUT are connected to BCM 18, 19, and 20 respectively. All clocks look good and at the correct frequency. I noticed that the clock waveforms were low until I forced BCM 18 & 19 to inputs from their state of ALT0. I enabled dtparam-is2-on in /boot/config.txt.

I used the instructions from adafruit to create the device in Linux. It worked, inasmuch as the device was created and reported by arecord -l. I can't say I know exactly what it is doing but everything I did understand looks OK to me.

I used arecord -c2 -f s32_le -r8000 -d10 -M test.wav to try to capture some data. It executed in well under a second. Nothing was connected to the audio inputs so I expected noise at minus 60-70dB or so. The file size, as expected, 640044 bytes, which is consistent with 10 seconds of stereo 32 bit floats at 8kHz. The problem is, of course, that it should take 10 seconds to capture this many samples. Using the time command I measured the actual capture rate at 1153x nominal. For instance, specifying 1000 seconds using -d1000 executes in around .93 - .94 seconds. Unsurprisingly it sometimes produces overruns. Changing the clock speed to 8192000 actually increases the run time to just over 1 second.

I tried using the -t 0 flag in pigpiod as I'd read in this forum that it might otherwise interfere with i2s without any change in behaviour. It seems to me that the breakout board is innocent in that if it provides a reasonable clock signal arecord should capture in real time.

Random suggestions welcome! I do want to stick with this cheap interface, however, as I'd like to build at least 20 in this configuration.


1 Answer 1


I now have it working, at least to the point where it records noise at about -90dB at the correct rate. I don't know why the above method didn't work, but on the Raspberry Pi Forum there's a thread that started in 2012 about I2S and solutions have evolved. The one I was trying is from an earlier epoch it seems.

By installing a device tree overlay found here on GitHub, it appears to be working correctly, although I would like to figure out some tweaks (remove the phantom playback device, change the device number from 1 to 0, change the name). Next step will be to connect an oscillator to one of the channels to ensure the waveform is being captured correctly.

  • It is now broken again. I connected an audio generator and recorded a nice clean sine 1/2V P-P sine wave. Then I started working on another chip on the same breadboard and when I tried to record again it would not get any data. After some time messing around with it it went back to the original problem, even though the way I created the device was quite different. Sigh. If I figure it out I will report it here.
    – Deepstop
    Commented Nov 25, 2021 at 22:39
  • It is now fixed again. I'm not sure what fixed it, in the same way that I'm not sure how I broke it again. The changes I made were removing the DAC part of the device tree overlay so that only an input device was created; I believe I was on the wrong track trying to specify the I2S pins as inputs rather than alt0, as the latter seems to be the correct mode for PCM. Once they were changed to inputs, I don't think changing them back to alt0 worked. After changing dtoverlay, all I did was reboot and start the oscillator with pigs on pin 4, and now I'm back in business.
    – Deepstop
    Commented Nov 28, 2021 at 14:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.