STICKY: The I2S sound thread. [I2S works]

[HiassofT]

The "DAI ... not registered - will retry" messages are harmless, they are caused by deferred probing. The important thing is that you get the "i2s mapping ok" message, this means the driver loaded successfully.

I'm not familiar with that codec but I'd recommend checking the alsamixer settings - probably some volume mixers are muted.

so long,

Hias

[DanR]

It wasn't the mixer volume or muting it was me misreading the datasheet and crossing the wiring for i2s DIN and DOUT. I will now sink into the background and quietly accept the doughnut award!!

Thanks for your reply though, it made me realise it must be something stupid or a broken codec. It was something stupid though ie me!!

Dan

[mhelin]

If you want to use the codec in left-justified mode you also have to use the left-justified dai format (SND_SOC_DAIFMT_LEFT_J).

But, I would not recommend doing that. bcm2835-i2 only operates correctly in left-justified mode if it is the frame master. If it's the slave left-right channel swaps can occur.

Your codec seems to require mclk synchronized with lrclk/bck when it's used in slave mode, something bcm2835 cannot provide. And using your codec as master with left-justified mode won't work well with bcm2835-i2s.

So, better use your AK5385 in I2S mode.

so long,

Hias

Why is that left-justified mode more prone to errors than I2S? LRCLK phase problem maybe, PCM DAI cannot detect the first LRCLK edge?

Anyway, it is also possible to use clock slave mode where the master clock (not needed by dai) and bit clock are generated on the hat externally, and PCM DAI generates the frame clock as frame master, anyone played with that? I think that should also make it possible to use the left-justified mode, and avoid that 2ns jitter @48k for an example.

[HiassofT]

Why is that left-justified mode more prone to errors than I2S? LRCLK phase problem maybe, PCM DAI cannot detect the first LRCLK edge?

It's probably a limitation in the hardware implementation of the I2S block. My guess is the sync logic needs at least one clock cycle between the leading edge of LRCLK and the start of data to reset a counter, flag, whatever - so DSP B and left justified modes don't sync properly when bcm2835 is a frame slave.

Anyway, it is also possible to use clock slave mode where the master clock (not needed by dai) and bit clock are generated on the hat externally, and PCM DAI generates the frame clock as frame master, anyone played with that? I think that should also make it possible to use the left-justified mode, and avoid that 2ns jitter @48k for an example.

I think that could work, if the codec supports the combination of being bitclock master and frame slave and if it supports being frame slave in left-justified mode. bcm2835 should support bitclock-master/frame-slave mode (it's implemented, but I haven't tested that) but quite a lot of codecs don't allow independent master/slave selection of frame and bitclock and several codecs also don't support left justified or DSP B mode as frame slave. If you find a codec that supports this combination you could give it a try.

so long,

Hias

[mhelin]

If you find a codec that supports this combination you could give it a try.

https://www.akm.com/akm/en/file/datasheet/AK4558EN.pdf

In this case there is the 3.072 MHz (@48 kHz) bit clock, AK4558 runs in PLL slave mode 1 and syncs to that bit clock like RPi. RPi is frame master and generates the LRCLK.

If you want to use 44.1 kHz sample rate just use two oscillators 3.072 MHz for 48 kHz and 2.8224 MHz for 44.1 kHz sample rates, and toggle the EN pin of oscillators using some GPIO pin to select either (connect inverter between the pins so only one is enabled at a time). The osc output pin goes in high impedance state when it's not enabled.

AK4558 codec in RPi clock slave mode

ak4558.png (55.39 KiB) Viewed 13365 times

You can also use any codec which requires MCLK by using for an example 12.288MHz oscillator for MCLK for codec, and the divide that by 4 using a flip-flop like 74HC74 or some counter chip like a 4-bit ripple counter 74HC93 for the bit clock. That would be actually easier as then you could use simpler codec without I2C/SPI codec control interface, AKM AK4556VT (https://www.akm.com/akm/en/file/datasheet/AK4556VT.pdf) for an example, and let RPi generate the LRCK. The AK4558 also would work fine in parallel mode (without I2C) as slave if master clock would be available. It's just so tiny chip to solder, and requires soldering the exposed pad under the chip to the PCB for cooling. It's got slightly better SNR though.

[komeda]

Hi, maybe someone here can help me out with my setup, because I don't really understand how to do this right:

I have a samplerate converter SRC4382 with I2S output and I have a HiFiBerry DAC+ Pro both connected to the according default I2S pins on the pi. The HiFiberry alone works fine and I want to add the SRC as an input.

I control/setup the SRC via I2C, which also works.
The SRC is getting it's I2S clock signals from the HiFiBerry's PCM5122. When the HiFiBerry driver is loaded, the SRC gets a clock and starts working, giving a valid I2S output-signal (verified on oscilloscope).

I tried creating the needed alsa interface with a simple-card overlay but I don't understand how to tell it to use the PCM5122 clocks.

Can anybody here point me in the right direction?

[mhelin]

Using overlays you propably have to play with the examples (couldn't find one with a separate DAC and ADC, maybe there is one) and use the dummy spdif_rx codec (see older messages in this thread regarding the PCM4202 ADC).

If you can compile kernel modules you could also convert the PCM51xx DAC to a codec with the capture properties. Just add something like this to codec drivers struct snd_soc_dai_driver initialisation:

Code: Select all

        .capture = {
		.stream_name = "Capture",
		.channels_min = 2,
		.channels_max = 2,
	},
       .symmetric_rates = 1,
       .symmetric_formats = 1,

You should maybe also copy the .rates and .formats from the .playback initialization.

[mateusfig]

Anybody did try connect (I2S) ES9028 PRO board to Raspberry? I tried it out and I could get any sound.

[sivakumar.skdu]

Hi @stephan_o / All

Did you get a chance to check the Modules pcm4202 & rpi-4202-adc working on the Raspberry boards with PCM4202 ADC.
We have plan of designing RaPi3 board with PCM4202 ADC. And plan to use pcm4202 & rpi-4202-adc modules with support of S16_LE, 44100Hz, stereo input.
Thanking you.

Regards
S.Sivakumar

[mateusfig]

Anybody did try connect (I2S) ES9028 PRO board to Raspberry? I tried it out and I could get any sound.

Please, any help about my question?

[MrPolnareff]

Hi,
I'm currently trying to write a device tree overlay to add a TDM input to the raspberry pi (Raspberry Pi 3b+ Raspbian stretch).
The input will contain 8 channels. So in one frame, i should have 8 slots of 32 bits each.
I've tried to start with the simple_card overlay from dmesg i have this error: set_tdm_slot error.
Could someone help me writing (or have) a DT overlay implementing multiple channels input on the raspberry Pi ?

thank you,
MrPolnareff.

EDIT: By reading the Broadcom 2835 documentation(p119), it seems that the PCM interface of the raspberry can't be more than 2 channels.

[MKSounds]

Which kernel driver are you using?

Codec drivers like spdif_rx support 16bit, 24bit (S24_LE) and 32bit (S32_LE, added to spdif-rx in kernel 4.16) and this is working fine - I've used 24bit recording with the Cirrus Logic audio card.

Hi Hias/all,

just red what you mentioned about the 32 bit support.

I'm again working on the dsp connection to the raspi. I'm using Volumio 2.575 with kernel version 4.14.92+.
I took one of the simple-card overlays and modified it. The raspi runs as clock slave, because the dsp has to be the clock master.
I did a test overlay with 2 channels and 16 bit slot width. That is working perfect with Airplay on Volumio (44,1 kHz, 16 bit).

Now I need to fix the slot width to 32 bit to handle 24 bit on other system components. Therefore I configured
dai-tdm-slot-num = <2>;
dai-tdm-slot-width = <32>;
The clocks from the dsp are ok, I checked them with the scope. But no sound. As I think the 16 bit data from airplay should be padded automatically in the 32 bit slot (I2S mode, left-justified, delayed by 1).

I changed the output bit depth of shairport-sync to S32 which didn't fix the problem.
Now I was wondering if there is a problem with the simple-card module.
Any thoughts what could be the cause of the problem?

Greets, Markus

[DrV]

My question is not an audio question as such but highly I2S related. I have been trying to read this thread plus various RPi Linux sources back and forth, but there are still a couple of questions which would need an answer.

I am using the I2S interface to capture bit stream data from a measurement instrument. The instrument needs (or supplies) a fixed frequency (2..12 MHz) and outputs a single bit data stream at that frequency. I need to capture that data stream for further processing. So, in audio terms, I have a sound card which only has a stereo input channel (currently using 2 x 32 bits).

I have managed to patch up something that works quite reliably. I followed the AdaFruit guide at https://learn.adafruit.com/adafruit-i2s ... g-and-test. There I was successful, but very unfortunately the infrastructure does not allow flexible sample rates.

To achieve the flexible sample rates, I took asoc-i2s-loader.c and renamed the codec and codec_dai. Then I took dmic.c and stripped it heavily, the most important change being changing the available rates to SNDRV_PCM_RATE_CONTINUOUS plus removing the multi-channel support. After a little bit of trial-and-error without really understanding what is going on, everything almost works with these two kernel modules loaded.

I am not very proud of what I have done. I have the lingering feeling that what I did could have been accomplished with some clever DT overlays without twiddling with my own patched kernel modules. I would very much like something that leans on standard components, as I really do not want to go through the steps for all kernel version changes. Is there such a way? The AdaFruit instructions are a bit oldish, and a lot seems to have happened since.

Another very strange thing is that I have problems setting some sample rates. If I set a sample rate between approximately 150000 and 151500 samples/s (9 600 000 .. 9 700 000 bits/s), I always get exactly 9.6 MHz bit clock. Any other bit rates are ok, but that small gap is very odd. I traced the issue with a frequency counter, but actually /sys/kernel/debug/clk/clk_summary agrees with me. The Alsa layer happily reports, e.g. 150 780 samples/s (9 649 920 bit/s) with snd_pcm_hw_params_set_rate_near(), but Linux' clock system gives PCM clock of exactly 9 600 000 Hz.

I tried to follow where the I2S clock is actually set, but got somehow lost in linux/drivers/clk/bcm/clk-bcm2835.c. However, it might be that the clock setting error happens somewhat earlier in the Alsa - I2S - Linux clk (clk_set_rate) chain. I would also be interested in seeing what kind of MASH parameters the clock divisor uses in this case, but cannot find where they are set. (I am not so much worried about the jitter of the 500 MHz clock, but the divisor jitter is of high interest.)

Any advice to either of my problems?

[scales11]

I am not sure if this would be the correct place to ask, but could my issue with an i2c microphone be helped here?
https://www.raspberrypi.org/forums/view ... 3&t=243154

[flatmax]

About the Pi4,

I see that both Pi4 and Pi3 have their dts linking back to bcm283x.dtsi. This file defines their i2s hardware.
As they have the same i2s hardware definitions, I am assuming the same i2s silicon is ported from the bcm2835 to the bcm2311 chip .... which means status quo for the I2S software.

Can anyone confirm (from the official grape vine) that the i2s silicon is common between the P3 and Pi4 ?

Matt

[naazsimra]

What I understand from the code:
*(clk+0x26) and *(clk+0x27) are the two registers given by Gert, 0x7E101098 and 0x7E10109C.

The value " 0x5A000000 | 3<<12 | 1<<9 " translates to 01011010.00000000.00110010.00000000 in binary.
So if we extract bits 23-12 we get the integer part: 00000000.0011 (3), and the fractional part 0010 which means 0.125.
You can check the conversions here: http://www.easysurf.cc/cnver17.htm#bf2tobf10 .

For 44100ks (1411200Hz), assuming 3.15 divider produces 6144000Hz, we can compute the required divider of 13.605 . This translates to a value of 0b01011010.00000000.11011001.10101110 or 0x5A00D9AE.

Can anyone confirm if my numbers are correct?
Also, regarding the required pins for I2S, I see two sets of pins in table 6-31 in the BCM2835 datasheet. One is for ALT0 alternative function assignments, at GPIO18-GPIO21 and not all 4 are available.
The other one is for ALT2 at GPIO28-GPIO31, physically available on the board.
Can we switch to these ones (ALT2) without affecting the behavior of other features on the GPIO connector?

Also try this site : https://www.easyunitconverter.com/binary-converter

[okenido]

I'm currently trying to use a 8 channel DAC the PCM1960 in TDM mode (one I2S interface to control multiple outputs) with my raspberry 3B+ : http://www.ti.com/lit/ds/symlink/pcm1690.pdf

Unfortunately it's one of those requiring a Master Clock in addition to the three I2S wires, master clock has to be a multiple of sampling frequency, usually 256 x Fs.

I followed the application schematic provided in the datasheet,


I've been trying generating this clock with the internal rpi's PLLD by providing a custom dts-blob.bin file, the signal seems to be generated but the DAC does nothing, draws 0.5mA from +3.3 and +5V and outputs remains silent (it has separate power supply voltages for digital and analog part).

I played around with some pin settings but nothing, either in simple or TDM mode, no matter which settings i use with FMT/MODE/MUTE pins. I'm guessing I can't generate this arbitrary clock frequency and expect it to match the bits sent on LCK/BCK/DOUT ?

I don't know if I have the right chip to work with the RPI... I'd just need the easiest chip possible that supports TDM, at least 4 channels output.

[Xavier_S]

1- The PCM1690 needs to get its BCK and LRCK from the I2S. Therefore for each one of these signals, it is an I2S clock slave, and your driver must be configured accordingly.

2- When you configure your DAI Link so that your codec is a clock slave, then automatically the other end of the link is supposed to be a clock master, and the device attached to this other end is configured accordingly by the driver. In most situations, this other end is the Raspberry Pi audio subsystem. (As you probably know, the Rpi audio subsystem can in no way issue more than 2 channels through I2S, so you have to find another source for your 6 other channels).
However the PCM1690 also needs an SCK that is an exact multiple of LRCK (at least 128x), and which is not part of the I2S specification. Unfortunately, when configured as a clock master the Rpi audio subsystem has no provision for issuing such a clock. On the other hand it issues BCK, which is 32x or 64x LRCK depending on your DAI configuration, and which you could multiply yourself with a PLL to get the required SCK (but note that BCK usually halts when you stop streaming audio to your codec, so you want to make sure what your SCK behaviour would be in that case and how your system would respond to it).

3- Alternatively you can generate your own SCK, and make your own BCK and LRCK from it. In that case you want to configure both your codec and Rpi audio subsystem as clock slaves. Now if you do that you have to provide a master for each one of them; i.e., you will have to declare two distinct DAIs, and create your own sound card driver whose purpose will be to act as a master for both DAIs and route audio information between them. This is called a codec-codec link. You may find some inspiration by reading this post: viewtopic.php?f=44&t=8496&start=850 and the five following ones.
From the clock quality perspective this may be the best solution, because it allows you to pick an extremely low-noise clock source, which can only be beneficial to the quality of your audio. This is especially true if your sampling frequency is a member of the 44.1kHz family. Because 44100 is not an integer submultiple of the Raspberry's 19.2MHz oscillator, the Raspberry is known to be a poor clock source at these frequencies for audiophile applications, hence using an external clock source is highly recommended.

4- If you intend to use the Raspberry as a clock source anyway: you probably want to use pin GPIO4 (connector pin 7) configured as GPCLK0. Depending on the frequency you choose and the availability of your HDMI interface, you may get OSC (19.2 MHz), PLLH (216MHz) or PLLD (500MHz) as a clock source. See here for details: https://www.raspberrypi.org/forums/view ... 7#p1454937.

[okenido]

I made the clock on the Raspberry Pi gpio #4 (seemed the easiest solution to me) but it won't wake up the DAC, this is what I used in dt-blob.dts (took from a post on this forum) :

Code: Select all

// in pin_config section
pin@p4  {
                function = "gp_clk";
                termination = "no_pulling";
            }; // GPCKL0
            
// in videocore section
clock_routing {
        vco@PLLA {
            freq = <1228800000>;
        };
        chan@APER {
            div = <4>;
        };
        clock@GPCLK0 {
            pll = "PLLA";
            chan = "APER";
        };
    };

    clock_setup {
        clock@GPCLK0 {
            freq = <12288000>;
        };
    };

12288000/256 = 48000 for 48Khz. I don't use the HDMI output.

Is it wrong compared to the solution on the link you gave ?

I can't check it works since I have no scope, but my meter says 1.6 VDC which could be the average of 3.3V peak to peak square wave.

I use the bare metal Circle library, which handle I2S. Worked great with the PCM5102A, i'm just having problems because of this Master Clock (SCKI) requirement on this DAC which isn't needed on the PCM5102A.

The little dude :

[Xavier_S]

Is it wrong compared to the solution on the link you gave ?

If you read carefully PhilE's answer to this post: viewtopic.php?t=136988, you will see that it is not the way to go...

I can't check it works since I have no scope, but my meter says 1.6 VDC which could be the average of 3.3V peak to peak square wave.

You don't need a scope to check what goes out of GPIO4. A very inexpensive 8-digit frequency meter is what you absolutely want to use. And by the way, you can't draw any conclusion from the 1.6V you measure: it could as well be the result of a voltage divider between your meter and a weak pull-up inside GPIO4 (although your dt-blob says termination = "no_pulling", but did you make sure that it was loaded correctly?)

[bricolodu13]

Hello,

I'm trying to slave my Pi and my DAC to an external Clock
I'm using a RPi 3B+ with Dietpi 4.19.42-v7+

As a DAC, im using the Adafruit MAX98357 I2S Class-D Mono Amp
As an external clock, I'm using the Adafruit Si5351 Clock Generator Breakout

I get music without issue when the Amp is connected to the Pi

The Si5351 External clock is working fine, checked on the scope. It provides BCK (2,8224MHz) and optionnally LRCK (44K1Hz)

I have modified the I2S Driver so that the Pi is Slaved to the external Si Clock
HOWEVER, the Pi is still providing BCK and LRCK as if in Master Mode

I first tried the following overlay :

Code: Select all

/dts-v1/;
/plugin/;

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

                        cpu_port: port {
                                cpu_endpoint: endpoint {
                                        remote-endpoint = <&codec_endpoint>;
                                        dai-format = "i2s";
                                        bitclock-slave;
                                        frame-master;
                                };
                        };
                };
        };


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

                                codec_port: port {
                                        codec_endpoint: endpoint {
                                                remote-endpoint = <&cpu_endpoin$
                                        };
                                };
                        };
                };
        };

        fragment@2 {
                target = <&sound>;
                __overlay__ {
                        compatible = "audio-graph-card";
                        label = "SlaveI2S";
                        dais = <&cpu_port>;
                        status = "okay";
                };
        };
};

The Rasberry is still MASTER

I also tried with

Code: Select all

                        cpu_port: port {
                                cpu_endpoint: endpoint {
                                        remote-endpoint = <&codec_endpoint>;
                                        dai-format = "i2s";
                                        bitclock-slave;
                                        frame-slave;

The Rasberry is still MASTER
Anything that I'm missing


Should it work, am I also supposed to slave the LRCK from the external Si Clock to the Pi and to the DAC ?
I initially planed ONLY slaving BCK from the external Si Clock to the Pi and to the DAC

Best regards,
Jean

[Xavier_S]

In your codec_port you have a typo: remote-endpoint = <&cpu_endpoin$ instead of remote-endpoint = <&cpu_endpoint>;.
Is it just in your post, or in your overlay as well?

[HiassofT]

bitclock-slave and frame-slave aren't valid device tree properties, so they'll be simply ignored. You have to set bitclock-master and frame-master on the other (codec) endpoint instead.

see https://github.com/raspberrypi/linux/bl ... h-card.txt

so long,

Hias

[bricolodu13]

Hi Hias/all

I got your point

Howerver, I still can't get any music !
At best I have weird noise.

Here is what I did.
1/ Enter the bit clock and the LRCK to the Pi
with the following

Code: Select all

/dts-v1/;
/plugin/;

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

                        cpu_port: port {
                                cpu_endpoint: endpoint {
                                        remote-endpoint = <&codec_endpoint>;
                                        dai-format = "i2s";
                                };
                        };
                };
        };


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

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


        fragment@2 {
                target = <&sound>;
                __overlay__ {
                        compatible = "audio-graph-card";
                        label = "SlaveI2S";
                        dais = <&cpu_port>;
                        status = "okay";
                };
        };
};

Result = NO sound at all

2/ Enter only bit clock to the Pi that is generating the LRCK
with the following modification

Code: Select all

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

Result = Weird noise sound

In both case I get the clock generated

What am I missing

Best regards,
Jean

[HiassofT]

You may need to use bitclock-master and frame-master properties with the codec phandle in the CPU node, like this:

Code: Select all

                        cpu_port: port {
                                cpu_endpoint: endpoint {
                                        remote-endpoint = <&codec_endpoint>;
                                        frame-master = <&codec_endpoint>;
                                        bitclock-master = <&codec_endpoint>;
                                        dai-format = "i2s";
                                };
                        };

Not sure if the old/simple form (boolean property, no phandle) works with audio graph card - checking through my samples it seems I've only used the full form with phandle.

You may also need to specify the bclk ratio and set it to the values your codec is generating, eg add "dai-tdm-slot-num = <2>;" and "dai-tdm-slot-width ="<32>;" if each LRCLK cycle contains 64 (2*32) bclk cycle. In slave mode RPi will only work fine if you got all parameters right (also check if the codec is actually using the I2S format or if it's some DSP or justified format).

With the codec running at a fixed frequency you should also create a ~/.asoundrc file to use a fixed format and sample rate - alsa will then resample and/or adjust the format to these settings if you try to play a file with different settings. Search this thread /or subforum), I think I posted info about that.

so long,

Hias