Page 36 of 36

Re: STICKY: The I2S sound thread.

Posted: Mon Jan 14, 2019 5:07 pm
by 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

Re: STICKY: The I2S sound thread.

Posted: Tue Jan 15, 2019 3:18 pm
by 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

Re: STICKY: The I2S sound thread.

Posted: Wed Jan 23, 2019 9:14 pm
by mhelin
HiassofT wrote:
Thu Nov 08, 2018 8:29 pm
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.

Re: STICKY: The I2S sound thread.

Posted: Thu Jan 24, 2019 12:30 pm
by HiassofT
mhelin wrote:
Wed Jan 23, 2019 9:14 pm
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

Re: STICKY: The I2S sound thread.

Posted: Thu Jan 24, 2019 7:07 pm
by 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.png
AK4558 codec in RPi clock slave mode
ak4558.png (55.39 KiB) Viewed 2098 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.

Re: STICKY: The I2S sound thread.

Posted: Fri Jan 25, 2019 10:25 am
by 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?

Re: STICKY: The I2S sound thread.

Posted: Tue Jan 29, 2019 7:54 pm
by 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.

Re: STICKY: The I2S sound thread.

Posted: Fri Feb 08, 2019 10:09 pm
by mateusfig
Anybody did try connect (I2S) ES9028 PRO board to Raspberry? I tried it out and I could get any sound.

Re: STICKY: The I2S sound thread.

Posted: Tue Feb 19, 2019 1:09 pm
by 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

Re: STICKY: The I2S sound thread.

Posted: Tue Feb 19, 2019 1:46 pm
by mateusfig
mateusfig wrote:
Fri Feb 08, 2019 10:09 pm
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?

Re: STICKY: The I2S sound thread.

Posted: Mon Feb 25, 2019 3:23 pm
by 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.

Re: STICKY: The I2S sound thread.

Posted: Wed May 15, 2019 8:54 pm
by MKSounds
HiassofT wrote:
Wed Dec 05, 2018 2:31 pm
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

Re: STICKY: The I2S sound thread.

Posted: Fri Jun 07, 2019 10:25 am
by 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?

Re: STICKY: The I2S sound thread.

Posted: Sun Jun 23, 2019 1:55 pm
by 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