STICKY: The I2S sound thread.

[bricolodu13]

Hi Hias,

It's working now.

I had an old asound.conf that was on the way, sorry !

I finally got it working with my yesterday code:

Code: Select all

                                codec_port: port {
                                        codec_endpoint: endpoint {
                                                remote-endpoint = <&cpu_endpoint>;
                                                bitclock-master;
                                                frame-master;
                                        };

Thank you very much for your help.

[okenido]

I switched to an AD1934 DAC chip since it has integrated PLL and it works on the Raspberry Pi 3B+ !

Now I want to use TDM to get more than a single stereo output (up to 4 stereo outs on AD1934), so I setup my DAC in TDM mode and write the data like this :

Ch1 L | Ch1 R | Ch2 L | Ch2R (two stereo 48khz channels in a 96khz stream)

But I only get the sound from channel 1, I think it's because the Raspberry's I2S system isn't configured to generate the appropriate LRCK signal for TDM so my DAC just won't get all the data.

I looked at a few posts telling about custom overlays to setup the system in TDM mode, I compiled the following example but it seems to have no effect at all :

Code: Select all

/dts-v1/;
/plugin/;

/ {
    compatible = "brcm,bcm2835", "brcm,bcm2836", "brcm,bcm2837","brcm,bcm2837B0","brcm,bcm2708", "brcm,bcm2709";


    fragment@0 {
        target-path = "/";
        __overlay__ {
            dual_soundcard: dual-soundcard {
                compatible = "simple-audio-card";
                simple-audio-card,name = "Dual";

                status="okay";

                capture_link: simple-audio-card,dai-link@0 {
                    format = "i2s";
                    bitclock-master = <&r_codec_dai>;
                    frame-master = <&r_codec_dai>;

                    r_cpu_dai: cpu {
                        sound-dai = <&i2s>;

                        dai-tdm-slot-num = <2>;
                        dai-tdm-slot-width = <128>;
                    };

                    r_codec_dai: codec {
                        sound-dai = <&codec_in>;
                    };
                };

                playback_link: simple-audio-card,dai-link@1 {
                    format = "i2s";
                    bitclock-master = <&p_codec_dai>;
                    frame-master = <&p_codec_dai>;

                    p_cpu_dai: cpu {
                        sound-dai = <&i2s>;

                        dai-tdm-slot-num = <2>;
                        dai-tdm-slot-width = <128>;
                    };

                    p_codec_dai: codec {
                        sound-dai = <&codec_out>;
                    };
                };
            };
        };
    };

    fragment@1 {
        target-path = "/";
        __overlay__ {
            codec_out: spdif-transmitter {
                #address-cells = <0>;
                #size-cells = <0>;
                #sound-dai-cells = <0>;
                compatible = "linux,spdif-dit";
                status = "okay";
            };
            codec_in: spdif-receiver {
                #address-cells = <0>;
                #size-cells = <0>;
                #sound-dai-cells = <0>;
                compatible = "linux,spdif-dir";
                status = "okay";
            };
        };
    };

    fragment@2 {
        target = <&i2s>;
        __overlay__ {
            #sound-dai-cells = <0>;
            status = "okay";
        };
    };

};

The documentation on the net is really awful : somewhere I read the DTB file should be put at the root folder, at other places they say to put it in "boot/overlays/"... sometimes it's .dtb other times it's .dtbo. It isn't even clear if the overlay must be referenced in /config.txt or /boot/config.txt.

I added "bcm2837" and "bcm2837B0" in the "compatible" variable because it seemed strange to me that my CPU (RPI 3B+) isn't referenced but I have no idea if I'm doing it right.

May someone tell me how to do this properly ?
I'm using the rasberry with bare metal code, but it should not be a problem since overlays are loaded before by start.elf ?

[HiassofT]

With bare metal code you can completely ignore the DT overlays, unless you have some code to interpret the FDT passed in from the bootloader. With Linux the DT overlays are used to configure the linux drivers.

Concerning TDM: While the bcm I2S block offers very flexible configuration it doesn't support more than 2 channels per frame -it's stereo only. Some people have used quirks to use it in multichannel configuration (while the base hardware is still running in stereo) but this is tricky and can lead to channel swaps/shifts if the clocks aren't started at very precise moments.

so long,

Hias

[okenido]

Yeah it seems complicated. I've tried to run I2S at 192Khz to write four 48Khz frames, while slowing down Frame Sync Length by a factor of 4 (FSLEN register, I guess it controls LRCLK ? => broadcom datasheet p.131 https://www.raspberrypi.org/documentati ... herals.pdf )

To match the expected format for my DAC :

https://www.analog.com/media/en/technic ... AD1934.pdf p.14

But I get no sound doing that.
In this mode my DAC seems a bit special since TDM LRCLK isn't just a pulse it's a stretched variant of the I2S (stereo) LRCLK, a square wave. It gave me some hope initially but maybe i'm misunderstanding.

Unfortunately I have no scope to see the signals... I ordered one, should receive it next week

[HiassofT]

Setting up the interface at four-times stereo rate is a good start.

If you run the bcm2835-i2s in clock slave mode FSLEN doesn't matter, it only check for the leading LRCLK edge. Just set it up as usual (eg 1 for DSP mode or sample length for I2S).

There is a quirk in bcm2835-i2s, once it's seen a LRCLK edge it'll keep transmitting data even if the LRCLK edge is missing on subsequent frames. So you can eg drive it with a LRCLK signal set up for 8 samples instead of 2 - this is what the audioinjector octo card seems to be doing.

The downside of this is that the bcm2835-i2s won't properly sync to LRCLK. When starting clocks at the exact specific moments it seems to be doable though (haven't really looked into the latter myself).

If you run bcm2835-i2s in (frame clock) master mode you could use an external divide-by-4 circuit (eg 2 flip-flops) on the LRCLK signal so 4 stereo frames will be combined into one 8-channel frame. Again you must take care yourself that the polarity and phase of the divided signal is correct (eg reset the divider and/or keep LRCLK high) before the first stereo sample is transmitted.

so long,

Hias

[okenido]

I use the raspberry in Master mode for the sake of simplicity ^^
I received my scope and it helped a lot. For some reason, chosing a Frame Sync Length (FSLEN) greater than the Frame Length (FLEN) causes LRCLK to stop working.
However, I can get the 256 BCLK per LRCLK if I just increase both FLEN and FSLEN, so i'll do a test to see if I can talk to my DAC now.

Normal I2S mode :


Increased only FSLEN... oops ! :


Both FLEN and FSLEN increased :


Yellow = LRCLK
Pink = BCLK
Blue = Data

[okenido]

Seems that I can only transfer the first 32 bits of the frame despite I set its length to 128. Or i'm missing something. Maybe the clock divider trick you explained is the only way to go

[HiassofT]

No, you are not missing anything. bcm2835-i2s will only transfer (max) 2 samples/channels per frame - this is what I meant with "stereo only".

You'll have to use one of the tricks I posted to pack 4 stereo frames into an 8-channel one.

so long,

Hias

[okenido]

Thanks that make sense, i'ill try that asap.

Learning by trial & error

[okenido]

-

[okenido]

-

[egawtry]

I have been searching and searching for an answer for this one (2 months so far), and I keep getting the runaround.

I have a working I2S send/recv at 192KHz with external clock. How the heck do I switch the sampling rate (96, 48, 44.1, etc)? I have been assuming it is via I2C, but nothing I do sends any data on the I2C bus when the sampling rate changes. I finally got it coded in the device tree to lock it out (UU on i2cdetect). i2cdump does send a signal when the sound driver is disabled.

I am not worried about what is in the output, only that something is available to detect when the sampling rate wants to change.

Could someone please help?

Thank You,
-Erik

Here is the device tree:

Code: Select all

/dts-v1/;
/plugin/;

// Device Tree Overlay for generic I2S audio output on Raspberry Pi

/ {
    compatible = "brcm,bcm2708";

    fragment@0 {
        target = <&sound>;
        __overlay__ {

            compatible = "simple-audio-card";
            simple-audio-card,name = "Danville-dspElite-Soundcard";
		//audio-codec = <&pcm5122>;		// Breaks it
			
            status="okay";
            capture_link: simple-audio-card,dai-link@0 {
                format = "i2s";
				
                bitclock-master = <&r_codec_dai>;
                frame-master = <&r_codec_dai>;

                r_cpu_dai: cpu {
                                sound-dai = <&i2s>;

				                 // TDM slot configuration - BCLK ratio: 64 x Fs (2 x 32 bit) 
                                dai-tdm-slot-num = <2>;
                                dai-tdm-slot-width = <32>;
                
				};

                r_codec_dai: codec {
                    sound-dai = <&codec_in>;
                };
            };
            playback_link: simple-audio-card,dai-link@1 {
                format = "i2s";
				
                bitclock-master = <&p_codec_dai>;
                frame-master = <&p_codec_dai>;

                p_cpu_dai: cpu {
                                sound-dai = <&i2s>;

				                 // TDM slot configuration - BCLK ratio: 64 x Fs (2 x 32 bit) 
                                dai-tdm-slot-num = <2>;
                                dai-tdm-slot-width = <32>;
                
				};

                p_codec_dai: codec {
                    sound-dai = <&codec_out>;
                };
            };
        };
    };

    fragment@1 {
        target-path = "/";
        __overlay__ {
            codec_out: spdif-transmitter {
                #address-cells = <0>;
                #size-cells = <0>;
                #sound-dai-cells = <0>;
                compatible = "linux,spdif-dit";
                status = "okay";
            };
	    codec_in: spdif-receiver {
                #address-cells = <0>;
                #size-cells = <0>;
                #sound-dai-cells = <0>;
		compatible = "linux,spdif-dir";
                status = "okay";
		};
	    };
    };

    fragment@2 {
        target = <&i2s>;
        __overlay__ {
            #sound-dai-cells = <0>;
            status = "okay";
        };
    };
    
	fragment@3 {
		target = <&i2c1>;
		__overlay__ {
			#address-cells = <1>;
			#size-cells = <0>;
			status = "okay";

			pcm5122@52 {
				#sound-dai-cells = <0>;
				compatible = "ti,pcm5122";
				reg = <0x52>;
				AVDD-supply = <&vdd_3v3_reg>;
				DVDD-supply = <&vdd_3v3_reg>;
				CPVDD-supply = <&vdd_3v3_reg>;
				status = "okay";
			};
		};
	};

};

[HiassofT]

You need to have a codec driver that handles sample rate / clock switching (in .hwparams).

That stuff is very specific to the codec / clock generator you are using (some use I2C, some SPI, some a bunch of GPIOs) so unless you are using some codec that's already supported in linux you need to write one that's matching your hardware.

so long,

Hias

[egawtry]

Hias,

You are the first person to give me an actual idea in months of trying. Please explain. Is there a help link somewhere hidden on ".hwparams"?

Thanks,
-Erik

[HiassofT]

Have a look at the kernel documentation - Documentation/sound in the kernel tree or online here: https://www.kernel.org/doc/html/v4.19/sound/index.html

"Writing an ALSA driver" is a good start, it contains also info what hw_parans should do and how ALSA in general works.

The ASoC sections may also be of interest to you, especially the "ASoC Codec Driver Class" section.

Also have a look at the codec drivers in sound/soc/codecs - eg cs4349.c (which is a rather simple one).

Edit: These slides contain a nice introduction into ASoC https://elinux.org/images/b/b5/Belloni-alsa-asoc.pdf and are worth a read as well.

so long,

Hias

[davefi]

Hi all, I've tried searching but there is so much information in this, and other threads, I am completely confused! I have no experience with audio on Linux, and not that much (recent at least) experience with Linux fullstop!

I purchased the Adafruit MEMS microphone, and have attempted to follow https://learn.adafruit.com/adafruit-i2s ... g-and-test to get things working (as it looked pretty straightforward).... however, I am having zero luck

I have followed the instructions and when I try and load the compiled module, I get an error:

pi@raspberrypi:~/rpi-i2s-audio $ sudo insmod my_loader.ko
insmod: ERROR: could not insert module my_loader.ko: Invalid module format

I'm trying this on a Raspberry Pi 4, and wondered if that might be the issue?

Does anyone have any suggestions/ideas?

Thank you in advance!

[JeremyBirch66]

I am also trying to install the I2S module on Pi4 and get:
pi@raspberrypi:~/rpi-i2s-audio $ sudo insmod my_loader.ko
insmod: ERROR: could not insert module my_loader.ko: Invalid module format

I have tried a very simple 'hello world' module and get the same - both of these worked previously on Pi3B+

Normally 'Invalid module format' means the module has been built against different headers than the currently running kernel, but I have run the checks:
'uname -r' gives 4.19.66-v7l+
'modinfo module.ko' gives: vermagic: 4.19.66-v7l+ SMP mod_unload modversions ARMv7 p2v8

so as far as I can see the headers should be the same as the kernel and the module should be valid.
'ls /lib/modules' lists 4.19.66-v7l+ (amongst others)
however I do find that 'sudo apt-cache search linux-headers' does not list anything beyond 4.18.0, and similarly 'sudo apt-get install linux-headers-4.19.66-v7l+' (or any variant on it) fails

so - what is going on ? How can I build a valid module that I can install in the Pi4 kernel? This is a complete blocking issue for me.

[JeremyBirch66]

I may have solved my own query here. Having done this (for the hello world module):
sudo apt-get install raspberrypi-kernel-headers
make clean
make
sudo insmod module.ko

I no longer get the warning message, lsmod shows the module as being present, and dmesg shows the expected loading message

Now to try I2S module ... and it works too!

Snag is that the ASOC CPU DAI magic number is wrong - to get it right do:
sudo mount -t debugfs debugs /sys/kernel/debug
sudo cat /sys/kernel/debug/asoc/dais

this should list the *.i2s module that needs to be referenced in my_loader.c - I think you need to change all occurrences of
3f203000.i2s
with
fe203000.i2s (the value from sudo cat /sys/kernel/debug/asoc/dais)

having done this, rebuilt the module and then insmod'd it I see this at the end of dmesg:
[ 5655.738151] my_loader: loading out-of-tree module taints kernel.
[ 5655.749259] request module load 'bcm2708-dmaengine': 0
[ 5655.751188] register platform device 'asoc-simple-card': 0
[ 5655.752924] Hello World
[ 5655.768269] asoc-simple-card asoc-simple-card.0: snd-soc-dummy-dai <-> fe203000.i2s mapping ok

Hurrah!

furthermore if I do arecord -l I get:
card 2: sndrpisimplecar [snd_rpi_simple_card], device 0: simple-card_codec_link snd-soc-dummy-dai-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0

Hurrah again!

Now to see if we can get actual sound out of it ...

[davefi]

Awesome news JeremyBirch66! Thank you for firstly confirming I was not going mad (I tried it 3 times!), but more importantly for the solution - I shall give that a try tomorrow

[KittyLitter]

PDM Microphones -- Or how I learned to stop loving life and desire lead in the head

I bought some Knowles Sisonic SPH0641LU4H PDM microphones which I would like to use with an RPI 3. I wired one up to the PCM/I2S gpio ports and did an ugly hack on linux/sound/soc/bcm/bcm2835-i2s.c to enable the hardware CIC filter and force a 4.8ish MHz bclk. It works in the sense that I can record 32-bit sound with the decimation set to 32x. I used another pi to play a chirp from 1kHz to 96kHz to confirm it is picking up ultrasound without trouble. It also records bat sonar nicely.

That was fairly easy. What has left me with damaged walls and self inflicted skull fractures is trying to get 16x decimation and 16-bit recording to work. For some reason the audio data seems to switch to big endian, or there are extra or missing bytes in the wav file, or something I don't comprehend is going on. I can play the recording in Audacity by opening the wave as raw data and telling it is big endian, or there is a 1(?) byte offset. I can see the chirp on the waterfall plot and hear soft ambient sounds, but there is a heck of a lot of clipping--the volume looks maxed out for some reason.

Does anyone have any ideas of what may be going wrong?

Am I re-inventing the wheel? I've spent many hours wading through irrelevant search results, but maybe I missed something.

[JeremyBirch66]

here are the exact steps I did (NB I did NOT run rpi-update as that gives a very nasty warning and I think it actually makes things worse...)

see
https://learn.adafruit.com/adafruit-i2s ... g-and-test

edit /boot/config.txt to uncomment dtparam=i2s=on
sudo nano /etc/modules : Add snd-bcm2835 on its own line
sudo reboot
lsmod | grep snd - should see snd_bcm2835 & i2s
kernel:

sudo apt-get install git bc libncurses5-dev bison flex libssl-dev

sudo wget https://raw.githubusercontent.com/notro ... rpi-source -O /usr/bin/rpi-source
sudo chmod +x /usr/bin/rpi-source
/usr/bin/rpi-source -q --tag-update
rpi-source --skip-gcc

If the script pauses at this prompt: Code coverage for fuzzing (KCOV) [N/y/?] (NEW) - just press enter
sudo mount -t debugfs debugs /sys/kernel/debug

git clone https://github.com/PaulCreaser/rpi-i2s-audio
cd rpi-i2s-audio
sudo cat /sys/kernel/debug/asoc/dais
this should show the *.i2s module you need to reference:
20203000.i2s : PiZero
3f203000.i2s : Pi2 and Pi3
fe203000.i2s : Pi4

edit my_loader.c to change 3f203000 to fe203000 in both places (for pi4)
sudo apt-get install raspberrypi-kernel-headers

make -C /lib/modules/$(uname -r )/build M=$(pwd) modules
sudo insmod my_loader.ko

modinfo my_loader.ko should show relevant version (matches uname -r)

sudo insmod my_loader.ko

this should go in cleanly, dmesg shows:
[ 422.528852] my_loader: disagrees about version of symbol module_layout
[ 602.627904] my_loader: loading out-of-tree module taints kernel.
[ 602.639081] request module load 'bcm2708-dmaengine': 0
[ 602.641010] register platform device 'asoc-simple-card': 0
[ 602.642762] Hello World
[ 602.660789] asoc-simple-card asoc-simple-card.0: snd-soc-dummy-dai <-> fe203000.i2s mapping ok

not sure about the disagrees line though

[Rolerex]

Hello everyone,

@KittyLitter

Does anyone have any ideas of what may be going wrong?

I'm also trying to use a PDM Microphone myself. I went throught the BCM2835 Datasheet to look at some of the features:
https://cdn-shop.adafruit.com/product-f ... asheet.pdf
And it's indeed capable of using a CIC decimation filter. I suppose your hack involve some registers modifications. If you want to switch from 32 to 16 decimation, have you seen the 8.6 PDM Input Mode Operation section ?
It's seems you have to modify the PDMN register and the OSR , which stands for Over Sampling Rate. This OSR seems to be a software parameter and change with the decimation.

Is it possible to know what did you modify in the bcm2835-i2s module ?

I'm trying to use a microphone to get a 48kHz signal, with a 3.072MHz Clock, whatever the decimation, but 32 would be great. Hit me if you have some info.

[egawtry]

Have a look at the kernel documentation - Documentation/sound in the kernel tree or online here: https://www.kernel.org/doc/html/v4.19/sound/index.html

"Writing an ALSA driver" is a good start, it contains also info what hw_parans should do and how ALSA in general works.

The ASoC sections may also be of interest to you, especially the "ASoC Codec Driver Class" section.

Also have a look at the codec drivers in sound/soc/codecs - eg cs4349.c (which is a rather simple one).

Edit: These slides contain a nice introduction into ASoC https://elinux.org/images/b/b5/Belloni-alsa-asoc.pdf and are worth a read as well.

Thanks, Hias.

Rather than spend all the time developing my own driver and figuring out how to interface it, do you know of any built-in driver that has an I2S client with I2C master?

Thanks again,

-Erik

[HiassofT]

Rather than spend all the time developing my own driver and figuring out how to interface it, do you know of any built-in driver that has an I2S client with I2C master?

There are plenty - eg pcm512x or wm8804 are common codecs and used in several RPi audio cards. If you use one of these chips you can reuse the existing drivers / DT overlays.

so long,

Hias

[MikeDB]

PDM Microphones -- Or how I learned to stop loving life and desire lead in the head

.....

For some reason the audio data seems to switch to big endian, .

Both the AES and the telecomms standard bodies defined big endian as the standard for digital audio almost a lifetime ago. Of course not all audio follows that, but most do, unless you are Apple and try to force a change with their AIFF-C nonsense.