Rolerex
Posts: 2
Joined: Fri Aug 30, 2019 9:39 am

Re: STICKY: The I2S sound thread.

Tue Sep 17, 2019 10:42 am

Hello again,

I finally managed to record with a pdm microphone a 16 bits pcm, 192000Hz, mono channel signal and a 32 bits pcm, 96000Hz, mono channel signal. I'm using a RPi 3.B
Here are the steps:
1/ I picked this loader to have a soundcard showing up in alsa. https://github.com/PaulCreaser/rpi-i2s-audio. I compiled it and put it in /lib/modules/$(uname -r) which is 4.14.79-v7+ for me. I added "my_loader" in /etc/modules which is the name of the .ko file compiled. I also added "snd-bcm2835", i'm not sure if it's necessary but i did it anyway.
2/ I modified bcm2835-i2s.c to fix the clock rate (bclk_rate) at 1536000 somewhere after the 380th line. You also have to add the following lines before it writes it in the register.

Code: Select all

	mode |= BCM2835_I2S_PDMN; // 32 bits
	mode |= BCM2835_I2S_PDME;
	
	regmap_write(dev->i2s_regmap, BCM2835_I2S_MODE_A_REG, mode);
Be carefull, the PDMN is only for 32bits, you can comment it or put a condition to get a 16 bits signal.
Then I compiled it and replace /lib/modules/$(uname -r)/kernel/sound/soc/bcm/snd-soc_bcm2538-i2s.ko with this new module.
3/ The output format is either 16 bit unsigned (for 16 bits) and 20 bits unsigned (for 32 bits). So you have to create a program which delete the offset -32767 (for 16 bits) and -524287 (for 32 bits). This allows you to convert the signal in signed signal, to be able to observe it in audacity.

If you consider modifying the sampling_rate, you can either switch from 16 bits to 32 bits or change the bclk_rate. This depends on the hardware you are using.
I think this is some kind of cheesy way to do it, but it works fine for me.
By the way, if you want to record the 20 bits signal, you can record it in 32 bits by shifting the bits of each sample by 12 (or multiply by 4096), otherwise your signal will be super small in audacity.

I hope this could help you ;)

piright
Posts: 1
Joined: Mon Oct 21, 2019 12:05 pm

Re: STICKY: The I2S sound thread.

Mon Oct 21, 2019 12:17 pm

Hi @Rolerex, I would like to follow your steps so that I can record 16-bit. I've made necessary adjustments to the source file in https://github.com/torvalds/linux/blob/ ... 2835-i2s.c . However when I try to compile with

Code: Select all

make -C /lib/modules/$(uname -r )/build M=$(pwd) modules
I encounter the following error
snd-soc-bcm2835-i2s.c:855:9: error: implicit declaration of function ‘devm_platform_ioremap_resource’; did you mean ‘devm_ioremap_resource’? [-Werror=implicit-function-declaration]
base = devm_platform_ioremap_resource(pdev, 0);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
devm_ioremap_resource
snd-soc-bcm2835-i2s.c:855:7: warning: assignment to ‘void *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
base = devm_platform_ioremap_resource(pdev, 0);
I've tried removing warning flags when compiling with -Wno-error but no success. I'm nervous to make any additional modifications to the original source file. I wonder if you encountered the same problem, if so how did you overcome it.

UPDATE: I've managed to compile by reverting to an older version of the source file. However, I'm trying to record at 16-bit 44100Hz but the recorded file is full of noise. I can't get any proper sound, I've commented out mode |= BCM2835_I2S_PDMN and I'm only using mode |= BCM2835_I2S_PDME

UPDATE2: I can now successfully record sound with a PDM microphone on a RPI. I uncommented mode |= BCM2835_I2S_PDMN. Using the following code I can record 16-bit at 48000Hz.


UPDATE3: I found out it was a current problem. My power supply didn't have enough current. I still get that initial pop sound when recording starts but other than that, everything is working. Thanks @Rolerex and every one else on this thread for your input.

Code: Select all

arecord -D plughw:1 -c1 -r 48000 -f S16_LE -d 60 -t wav -V mono -v test.wav
But now I keep hearing a popping/clicking sound on all my recordings? I'm not sure if it is the microphone or something related to ALSA? Anyone has an idea?
Rolerex wrote:
Tue Sep 17, 2019 10:42 am
Hello again,

I finally managed to record with a pdm microphone a 16 bits pcm, 192000Hz, mono channel signal and a 32 bits pcm, 96000Hz, mono channel signal. I'm using a RPi 3.B
Here are the steps:
1/ I picked this loader to have a soundcard showing up in alsa. https://github.com/PaulCreaser/rpi-i2s-audio. I compiled it and put it in /lib/modules/$(uname -r) which is 4.14.79-v7+ for me. I added "my_loader" in /etc/modules which is the name of the .ko file compiled. I also added "snd-bcm2835", i'm not sure if it's necessary but i did it anyway.
2/ I modified bcm2835-i2s.c to fix the clock rate (bclk_rate) at 1536000 somewhere after the 380th line. You also have to add the following lines before it writes it in the register.

Code: Select all

	mode |= BCM2835_I2S_PDMN; // 32 bits
	mode |= BCM2835_I2S_PDME;
	
	regmap_write(dev->i2s_regmap, BCM2835_I2S_MODE_A_REG, mode);
Be carefull, the PDMN is only for 32bits, you can comment it or put a condition to get a 16 bits signal.
Then I compiled it and replace /lib/modules/$(uname -r)/kernel/sound/soc/bcm/snd-soc_bcm2538-i2s.ko with this new module.
3/ The output format is either 16 bit unsigned (for 16 bits) and 20 bits unsigned (for 32 bits). So you have to create a program which delete the offset -32767 (for 16 bits) and -524287 (for 32 bits). This allows you to convert the signal in signed signal, to be able to observe it in audacity.

If you consider modifying the sampling_rate, you can either switch from 16 bits to 32 bits or change the bclk_rate. This depends on the hardware you are using.
I think this is some kind of cheesy way to do it, but it works fine for me.
By the way, if you want to record the 20 bits signal, you can record it in 32 bits by shifting the bits of each sample by 12 (or multiply by 4096), otherwise your signal will be super small in audacity.

I hope this could help you ;)

pkuhar
Posts: 4
Joined: Wed Jul 24, 2019 4:36 pm

Re: STICKY: The I2S sound thread.

Sat Dec 14, 2019 6:52 pm

Does anyone know if this PDM fix will work with RPI 4

hipgnosis
Posts: 2
Joined: Wed Dec 25, 2019 4:43 pm

Re: STICKY: The I2S sound thread.

Thu Dec 26, 2019 10:40 am

Hi,
i'm Raspy beginner ia have a question: i' ve read in the BCM 2835 datasheet "Jitter is therefore reduced by increasing the source clock frequency. In applications where
jitter is a concern, the fastest available clock source should be used."
I' ve found o a Isotemp OCXO Clock but the frequency is 19.44 Mhz not 19.2 Mhz, In your opinion is it possible to use it instead of the crappy 19.2 Mhz original raspy oscillator?

HiassofT
Posts: 305
Joined: Fri Jun 30, 2017 10:07 pm
Location: Salzburg, Austria
Contact: Website

Re: STICKY: The I2S sound thread.

Thu Dec 26, 2019 8:16 pm

hipgnosis wrote:
Thu Dec 26, 2019 10:40 am
i'm Raspy beginner ia have a question: i' ve read in the BCM 2835 datasheet "Jitter is therefore reduced by increasing the source clock frequency. In applications where
jitter is a concern, the fastest available clock source should be used."
I' ve found o a Isotemp OCXO Clock but the frequency is 19.44 Mhz not 19.2 Mhz, In your opinion is it possible to use it instead of the crappy 19.2 Mhz original raspy oscillator?
If you are concerned about jitter then it's best to not use the RPi as a I2S clock master but use two switchable oscillators (one for the 44.1kHz family of sample rates and another one for the 48kHz family) on the soundcard and configure the RPi as a clock slave.

Replacing the 19.2MHz oscillator with a differrent freuqency one quite certainly won't work without modifications of the closed source firmware. Also it won't help you much in respect to jitter as the I2S clock would still be derived from the 500MHz PLL via a fractional divider.

so long,

Hias

alexjaw
Posts: 5
Joined: Tue Dec 24, 2019 7:46 am

Re: STICKY: The I2S sound thread.

Sun Dec 29, 2019 8:08 am

I am trying to understand how machine drivers and codecs for raspberry are connected together. It's simple for a rs proto board https://www.mikroe.com/audio-codec-proto-board. Machine driver is snd_soc_rpi_proto and corresponing codec is snd_soc_wm8731. But how is for a board such as the mbed RS audio codec https://os.mbed.com/cookbook/RS-Audio-Codec? Earlier I think that it was managed by the machine driver rpi-dac, but now it's rpi-simple-soundcard, which defines a link to rpi-dac. But then, why is it linked to the codec pcm1794a when there is a specific tlv320 codec, tlv320aic23? Is it because rpi-simple-soundcard is a minimalistic driver that does not use all the bells and whistles provided by tlv320aic23?

I am working on a dsp codec project (based on adau1467) with playback, recording and i2c control. It is supposed to be interfaced with a raspberry. Therefore I really need to understand all details of ASoC.

Let me also express my gratitude to HiassofT for his engagement in this thread and sharing his knowledge with us.

Happy new year,
A.

Morocco_Bama
Posts: 10
Joined: Fri May 11, 2018 4:47 am

Re: STICKY: The I2S sound thread.

Wed Jan 08, 2020 2:37 am

Hi everyone,

Bear with me, I am currently trying to cycle through this entire thread to see if all my questions have been answered. I'm about 30% through.

I'm trying to make an audio sampler / looper / live-playback pedal using the Raspberry Pi. The ADC/DAC hat I've been using (or trying to use) is the PMOD I2S2 https://store.digilentinc.com/pmod-i2s2 ... nd-output/.

I thought it would be a fun challenge for me to implement my project at the register level from scratch, but after getting stuck with the PCM setup and coming here I'm starting to wonder if this is way beyond the scope of what I know (I'm pretty familiar with ARM and CPU programming, but not so much OS and kernel). I have the Pi in slave mode for PCM, as the PMOD can generate its own PCM_CLK and PCM_FS signals.

I had no troubles setting up the clock registers and (from what I can tell by debugging) I have set all the bits in the PCM control, mode, etc. registers correctly. But then I tried using DMA mode, and... well, looks like I'm not the only one who had troubles here.

Some questions:

Do I have the right approach here for DMA, or am I way off?

I set up 2 DMA channels.
One channel has a control block with SRC_ADDR = PCM_FIFO, and DEST_ADDR = &my_buffer, and is set up to listen for SRC_DREQ, which is set to the RX DREQ in the PERMAP bits (this is my RX DMA control block).
The other channel has a control block with SRC_ADDR = &my_buffer, DEST_ADDR = PCM_FIFO, DEST_DREQ, TX DREQ in PERMAP (TX DMA control block).
Both control blocks point back to themselves.
My thought process was that both RX and TX processes, since they're dictated by DREQ signals in DMA mode, are independent of each other, so they can be operated by seperate DMA registers. It sounds like I have to be careful to have &my_buffer be an address in uncached memory?

Duplex mode not possible?

Is it because there's only one PCM_FIFO? Can I not have TXON and RXON simultaneously? Will I have to "listen" for when DMA is writing or reading and set TXON or RXON accordingly each time? Can I not do both TXON and RXON at all?

Can I successfully get DMA mode running just by setting up my controllers, buffer and PCM interface properly at the register level? If not, what else do I need?

This is where the discussions in this thread start going over my head a bit. Are there default processes on the Pi that keep the DMA from operating / things that need to be switched off / things that need to be switched on? Do I have to modify the kernel itself in some manner (wouldn't know where to start)? Do I need to define a device tree overlay for the PMOD I2S2? I've seen a lot of comments about "ALSA drivers". I'm familiar with ALSA - my definition of a driver is just code that "drives" hardware? So if I write register-level code for PCM, isn't that just driver code? Do I need to use some set of ALSA libraries or something?

***

Anyways, sorry, if any or all of my above questions have already been answered. There's a lot to navigate in this thread. I'd love an abridged guide or tutorial on I2S setup for the Pi, if anybody has a link to an existing one?

moimeme4
Posts: 1
Joined: Wed Jan 29, 2020 7:11 am

Re: STICKY: The I2S sound thread.

Wed Jan 29, 2020 7:13 am

This worked form me on rpi4 with raspbian buster full.
Thanks a lot!
JeremyBirch66 wrote:
Sun Aug 25, 2019 3:05 pm
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

ngdievr
Posts: 9
Joined: Sun Jan 12, 2020 12:18 pm

Re: STICKY: The I2S sound thread.

Wed Feb 05, 2020 1:29 pm

Hi

im a bit noob in linux drivers and im trying to do a simple thing.
im using the higiberry-dac verlay as dummy card just to drive the i2s pins without using any actual HW adapter.
in nthis case this overlay only support rpi as i2s master.
i wuold like just to change the rpi to be an i2s slave for the bitclock and LRclk...
of course i can also provide external i2s mclk if needed but i would prefer as if the RPI could work just with the i2s bclk.

any chance someone can help on the needed modifications in the dts / overlay?

thanks

Naveh

alexjaw
Posts: 5
Joined: Tue Dec 24, 2019 7:46 am

Re: STICKY: The I2S sound thread.

Wed Feb 05, 2020 8:23 pm

ngdievr wrote:
Wed Feb 05, 2020 1:29 pm
i wuold like just to change the rpi to be an i2s slave for the bitclock and LRclk...
Check out the following discussion https://github.com/raspberrypi/linux/issues/2547, which I used for a project.

Another possibility (more elaborate, but might be of some interest) is to adjust the .dai_fmt for the simple-soundcard, https://github.com/raspberrypi/linux/bl ... oundcard.c. Compile the code and copy the corresponding kernel object file to the appropriate folder (/lib/modules/$(uname -r)/kernel/sound/soc/bcm/). Say that you go for the rpi-dac. You find its dai_fmt on lines 197 and 198. If you want the codec to be master for both BTCK and LRCK then change SND_SOC_DAIFMT_CBS_CFS to SND_SOC_DAIFMT_CBM_CFM. Add dtoverlay=rpi-dac to /boot/config.txt.

(For compilation you need linux source, see https://github.com/notro/rpi-source/wiki)

HiassofT
Posts: 305
Joined: Fri Jun 30, 2017 10:07 pm
Location: Salzburg, Austria
Contact: Website

Re: STICKY: The I2S sound thread.

Wed Feb 05, 2020 9:13 pm

Easiest way would be to create a DT overlay for simple-audio-card (or audio-graph-card) and use that instead. Just search this subforum and/or thread, I'm pretty sure I already posted info about that before.

so long,

Hias

ngdievr
Posts: 9
Joined: Sun Jan 12, 2020 12:18 pm

Re: STICKY: The I2S sound thread.

Thu Feb 06, 2020 6:55 am

Check out the following discussion https://github.com/raspberrypi/linux/issues/2547, which I used for a project.

Another possibility (more elaborate, but might be of some interest) is to adjust the .dai_fmt for the simple-soundcard, https://github.com/raspberrypi/linux/bl ... oundcard.c. Compile the code and copy the corresponding kernel object file to the appropriate folder (/lib/modules/$(uname -r)/kernel/sound/soc/bcm/). Say that you go for the rpi-dac. You find its dai_fmt on lines 197 and 198. If you want the codec to be master for both BTCK and LRCK then change SND_SOC_DAIFMT_CBS_CFS to SND_SOC_DAIFMT_CBM_CFM. Add dtoverlay=rpi-dac to /boot/config.txt.

(For compilation you need linux source, see https://github.com/notro/rpi-source/wiki)
Easiest way would be to create a DT overlay for simple-audio-card (or audio-graph-card) and use that instead. Just search this subforum and/or thread, I'm pretty sure I already posted info about that before.
thank you both.
if im understanding correctly though, this will only allow me to change the master/slave mode via reboot with using a different overlay.
im actually searching for an option to do that without any reboots. perhaps changing directly the bcm2835 i2s registers can be an option?
or can i create 2 cards using the same hw pins, one for master and one for slave and just use the one i need each time?

ngdievr
Posts: 9
Joined: Sun Jan 12, 2020 12:18 pm

Re: STICKY: The I2S sound thread.

Sat Feb 08, 2020 3:00 pm

thank you @Hias

ive spent some time reading and i believe i understand most

eventually i think ill go with 2 sound cards which will create a slave/master options on run time:

hifiberry-dac for master
simple sound card for slave

so some quick questions though:

codec:

1. is there a preference which codec to choose?
as a reminder i would like the RPI to be slave to bclk and lrclk, supporting 16,24,32 bit and 16khz-192khz
2. i would like a card with no i2c or spi control requirement, i will make sure the external i2s master is configured correctly in terms of bclk-lrclk (bclk is lrclk*bit_depth*2)
3. i would need both playback and recording

thanks

Naveh

ngdievr
Posts: 9
Joined: Sun Jan 12, 2020 12:18 pm

Re: STICKY: The I2S sound thread.

Tue Feb 11, 2020 1:58 pm

So i made some progress...
ive created a new DT overlay using SPDIF receiver and transmitter it is compiling and seems to run correctly (although havent tested recording).
main problem - it give me only playback device.
also, it also disabled my hifiberry overlay, so i guess they are overwriting each other?

looking at the spdif_receiver.c i can see its ofc course only a capture device and doesnt seem to support playback...
this brings me back to the first question, is there a codec i can use that allow both playback and capture and doesnt require any i2c control/ID?

my dts (i understand now that i cannot use both dir and dit for the spdif driver...):

Code: Select all

// Definitions for dspg_master audio add on soundcard
/dts-v1/;
/plugin/;

/ {
	compatible = "brcm,bcm2708";

	fragment@0 {
		target = <&i2s>;
		__overlay__ {
			status = "okay";
		};
	};

	fragment@1 {
		target-path = "/";
		__overlay__ {
			spdif_rx: spdif_rx {
				#address-cells = <0>;
				#size-cells = <0>;
				#sound-dai-cells = <0>;
				compatible = "linux,spdif-dir";
			};
		};
	};

	fragment@2 {
		target-path = "/";
		__overlay__ {
			spdif_tx: spdif_tx {
				#address-cells = <0>;
				#size-cells = <0>;
				#sound-dai-cells = <0>;
				compatible = "linux,spdif-dit";
			};
		};
	};


	fragment@3 {
		target = <&sound>;
		__overlay__ {
			compatible = "simple-audio-card";
			i2s-controller = <&i2s>;
			status = "okay";

			simple-audio-card,name = "dspg-master";

			simple-audio-card,format = "i2s";

			simple-audio-card,bitclock-master = <&sound_master>;
			simple-audio-card,frame-master = <&sound_master>;

			simple-audio-card,cpu {
				sound-dai = <&i2s>;
			};

			sound_master: simple-audio-card,codec {
				sound-dai = <&spdif_rx>;
			};
		};
	};
};

D2stux
Posts: 3
Joined: Fri Feb 14, 2020 1:39 pm

Re: STICKY: The I2S sound thread.

Fri Feb 14, 2020 1:56 pm

Hi,

in my current project I'm using a TDA7801, it's car amplifier chip with an i2s input, it's work well with "hifiberry-dac" overlay. But randomly, at boot or when i change song or play/pause or just when i launch a alsa speaker-test command the sound becomes very loud, is saturated with a lot of parasites.

How to find the cause, is it a problem of loss of clock synchronization or something else?

ngdievr
Posts: 9
Joined: Sun Jan 12, 2020 12:18 pm

Re: STICKY: The I2S sound thread.

Sun Feb 16, 2020 7:52 am

Hi,

in my current project I'm using a TDA7801, it's car amplifier chip with an i2s input, it's work well with "hifiberry-dac" overlay. But randomly, at boot or when i change song or play/pause or just when i launch a alsa speaker-test command the sound becomes very loud, is saturated with a lot of parasites.

How to find the cause, is it a problem of loss of clock synchronization or something else?
it depends on your codec but in general: unless configured different alsa does not keep the bitclk/LRclk alive between songs.
that being said, personally i use pulse audio server in order to both re-sample everything to a constant rate and bit depth and also to keep the clocks alive always.

D2stux
Posts: 3
Joined: Fri Feb 14, 2020 1:39 pm

Re: STICKY: The I2S sound thread.

Sun Feb 16, 2020 8:37 am

Ok, thx. i added a "complex_comvert" plugin with S32_SE argument in asound.conf, this increased the CLK value (BCK) from 1.4Mhz to 3.2Mhz.
It seems to have made things better.

ngdievr
Posts: 9
Joined: Sun Jan 12, 2020 12:18 pm

Re: STICKY: The I2S sound thread.

Wed Feb 19, 2020 1:50 pm

im trying to create 2 devices which 1 can be master on i2s clocks and the other slave.
here is the overlay:

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 = "dspg-Dual";

                status="okay";

                capture_link_master: 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>;
                    };

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

                playback_link_master: 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>;
                    };

                    p_codec_dai: codec {
                        sound-dai = <&codec_out>;
                    };
                };
                capture_link_slave: simple-audio-card,dai-link@2 {
                    format = "i2s";

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

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

                playback_link_slave: simple-audio-card,dai-link@3 {
                    format = "i2s";

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

                    ps_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";
        };
    };
};
its working only for RPI slave mode, not master.
any clues?

MKSounds
Posts: 8
Joined: Fri Apr 27, 2018 12:57 pm

Re: STICKY: The I2S sound thread.

Sat Feb 22, 2020 2:13 pm

Hi,
I randomly red the description of the audio-graph-card (audio-graph-card.txt: https://github.com/raspberrypi/linux/bl ... h-card.txt).
I saw that this module has the capability to resample the audio data (convert-rate = <48000>; in Example: Sampling Rate Conversion).
I was thinking if this would be a solution for the resampling problem of a fixed audio samplerate e.g. for DSPs in combination with the shairport-sync (Airplay) lib which writes the audio data directly to the output hardware. Therefore it is not possible to use the resampling of alsa subsystem.
How does the resampling work? Is there any documentation on this property? As always, the documentation of this issue is absolutely weak.

Kind regards,
Markus

HiassofT
Posts: 305
Joined: Fri Jun 30, 2017 10:07 pm
Location: Salzburg, Austria
Contact: Website

Re: STICKY: The I2S sound thread. [I2S works]

Sun Feb 23, 2020 10:05 pm

The convert-rate/convert-channels properties can only be used with hardware that has a sample rate converter built in. The only one I know of that's using this is renesas - see https://github.com/raspberrypi/linux/bl ... 2Crsnd.txt

In earlier kernel versions separate SCU versions of simple-card and audio-graph-card existed that were used by the renesas SoCs (see eg the DT bindings docs of the 4.19 kernel), but these were merged together a while ago.

So, for systems without hardware SRCs, like the RPi, the only way to resample audio is to do it in software (eg ALSA plugins).

so long,

Hias

ngdievr
Posts: 9
Joined: Sun Jan 12, 2020 12:18 pm

Re: STICKY: The I2S sound thread. [I2S works]

Mon Feb 24, 2020 8:49 am

Hi Hias

would you mind checking my earlier posts regarding dynamic master/slave usage?

im closer to where i need but missing the last mile i guess :)

thanks!
Naveh

HiassofT
Posts: 305
Joined: Fri Jun 30, 2017 10:07 pm
Location: Salzburg, Austria
Contact: Website

Re: STICKY: The I2S sound thread. [I2S works]

Wed Feb 26, 2020 4:29 pm

ngdievr wrote:
Mon Feb 24, 2020 8:49 am
would you mind checking my earlier posts regarding dynamic master/slave usage?
I don't think dynamic switching between master and slave mode is going to work this way. Just create two overlays (one for master, one for slave) and use the "dtoverlay"/"dtoverlay -r" commands to load/unload them during runtime.

so long,

Hias

itsikhefez
Posts: 2
Joined: Mon Mar 02, 2020 8:13 pm

Re: STICKY: The I2S sound thread. [I2S works]

Mon Mar 02, 2020 8:16 pm

I'm trying to modify one of the existing drivers in sound/soc/bcm to work with the AMB Gamma2 DAC module (WM8741 based).

've got raspbian setup and am perusing around https://github.com/raspberrypi/linux.../sound/soc/bcm

I'm thinking of using `rpi-proto` as a baseline and adapting to WM8741, or add another option in `rpi-simple-soundcard` that references the wm8741.

I've downloaded those source files locally and am a bit stuck on how to build, install and load the new module.
(Whether its a new source file based on `rpi-proto` or a modified version of the simple soundcard).

The `sound/soc/bcm` folder looks to be updated regularly with new drivers so this seems to be a pretty common thing.
Is there a resource or guide that helps ramp up on the development process?
Alternatively, is there a different approach to setup a new driver that uses an existing codec?

itsikhefez
Posts: 2
Joined: Mon Mar 02, 2020 8:13 pm

Re: STICKY: The I2S sound thread. [I2S works]

Wed Mar 04, 2020 11:29 am

In continuation to ^^, I've been able to build a basic driver with DKMS and it can be found in /lib/modules/.../kernel/sound/soc/bcm/snd-soc-<mydriver>.ko.

I've added this to /etc/modules and when running dmesg I get:
`[ 2.204423] snd_soc_<mydriver>: loading out-of-tree module taints kernel.`

but the DAC is not detected.
`aplay: device_list:272: no soundcards found...`

FWIW, I've copied basically the same impl of a driver that does work... so I'm thinking this is some sort of mapping somewhere.
Any tips on how to proceed or debug?

`

ngdievr
Posts: 9
Joined: Sun Jan 12, 2020 12:18 pm

Re: STICKY: The I2S sound thread. [I2S works]

Thu Mar 12, 2020 3:24 pm

I don't think dynamic switching between master and slave mode is going to work this way. Just create two overlays (one for master, one for slave) and use the "dtoverlay"/"dtoverlay -r" commands to load/unload them during runtime.
Thanks Hias

im able to do that and its working well with one exception that is not related but maybe you can share some light:
im using PulseAudio server as a backend. when using the hifiberry overlay i have no problem using PA with both 16 and 32 bit formats.
but when using the new Master overlay (simple sound card with SPDIF Rx and Tx) im only able to use 16 bit with pulse audio. sometimes also 32 bit works but only after reboot. when this issue happens, i get error message from PA:

Failed to find a working profile.
E: [pulseaudio] module.c: Failed to load module "module-alsa-card" (argument: "device_id="0" name="platform-dual-soundcard" card_name="alsa_card.platform-dual-soundcard" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes card_properties="module-udev-detect.discovered=1""): initialization failed.

now this happens only if i first load the slave overlay, remove it, and them load the master overlay.
i think something maybe getting corrupted but i cannot find what...
any clue?

thanks a lot
Naveh

Return to “Interfacing (DSI, CSI, I2C, etc.)”