raptorlightning
Posts: 2
Joined: Fri Jun 25, 2021 9:52 pm

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

Wed Jul 07, 2021 5:02 am

MikeDB wrote:
Tue Jun 29, 2021 4:53 am
@raptorlightning

I used to use ALSA and found you had to allow longer than expected I2S circular buffers in the system to keep it error-free. Never worked out why and went bare-metal in the end.
I'm not 100% sure what you mean by this and what the fix would be if I needed to use ALSA and ran into the same problem. The devices header for camillaDSP is rather simple and ALSA seems to be the only way to do it (avoiding PulseAudio, obviously). Is this something difficult to implement? Does it apply using the DT overlay phofman recommended? I don't care too much about audio delay as long as it's reasonably within human audio/video desync tolerance. Here's an example camillaDSP header set up to use the USBStreamer I have now:

Code: Select all

devices:
  samplerate: 44100
  chunksize: 1024
  target_level: 512
  capture:
    type: Alsa
    channels: 2
    device: "iec958:CARD=USBStreamer,DEV=0"
    format: S32LE
  playback:
    type: Alsa
    channels: 2
    device: "iec958:CARD=USBStreamer,DEV=0"
    format: S32LE
Error/glitch-free, bit-perfect functionality of the WM880x Rx --> I2S Raspi In --> I2S Raspi Out --> WM880x Tx chain is paramount (assuming no filtering is done by the camillaDSP software and it's just set to passthrough).
MikeDB wrote:
Tue Jun 29, 2021 4:53 am
@raptorlightning

One alternative you could consider is using a STM32H750 MCU instead of the WM880x devices as this comes with dual SPDIF I/O on chip and provides lots of support processing if needed, and then provides a unified I2S interface to the Pi.
Researching deeper into this idea, I've found quite a lot of people having headaches/confusion with this implementation. I like the ease-of-use aspect of the WM880x devices, and their clock performance/quality on both RX and TX. Jitter cleaning, FIFO buffering, known good tx/rx analog front-ends, etc. I've never had any issues with them that weren't PEBKAC ;).

Thank you both (phofman and MikeDB) for your help!

ajc9988
Posts: 1
Joined: Fri Aug 27, 2021 11:51 pm

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

Sat Aug 28, 2021 1:05 am

Hi. First post and new here, so please be gentle. Still reading through things and trying to find the best way to accomplish my goal.

Goal: Use an RPi4 to run an optimized FIR filter using the NEON SIMD instruction set in conjunction with an ADAU1701 doing the rest of the work in an active crossover/amplifier scenario to be built into a plate amp. At the moment, this is not commercial, just being done for a DIY hobby enthusiast building some tower speakers.

Background: fluid in google. Have compiled the ADI RPi4 5.4.y kernel ( https://wiki.analog.com/resources/tools ... aspberrypi ; https://github.com/analogdevicesinc/lin ... /rpi-5.4.y ). Still learning on how to compile driver modules (saw another post in this thread that answers that). Also unsure I got everything setup correctly on the kernel. I'm more of a Windows guy than Linux, so an answer and pointing me to more research is fine. I've done more with building computers than working on developer boards and designing circuits or anything like that.

Hardware: Wondom JAB5 (https://store.sure-electronics.com/imag ... asheet.pdf); Integrated Circuit Programmer 3 (https://store.sure-electronics.com/imag ... 0Guide.pdf (page 26 for pinout); Raspberry Pi 4b 4GB 40 pin

Question: which GPIO pins should be used to connect the devices? I am doing pre-processing with the ADAU1701, then after an infrasonic filter wanting to send the data to the RPi for application of a FIR filter, then return trip to then be split into the three-way crossover (with limiter on at least the subwoofer) and then out to the speakers (200W to 12" subwoofer, 80W to the 6.5" woofer, 100W to the tweeter)?

I can figure out from the schematics the MOSI and MISO (the JAB5 is master, so you use the master out slave in on each board and MISO for the return channel). The question comes in with connecting either MCLK, BCLK, or LRCLK to which GPIO pins (like RXD, SCLK, etc.)?

Edit:

Here is to give some more information on changes from RPi B+ to the RPI4b
https://kentaromitsuyasu.medium.com/cre ... e6f3ad0834
If you scroll down on this link, you see the diagram for the 40 pin gpio pinout. Below it, it describes how to connect the clock pins:
In other words, it seems that it should be connected to
PCM_CLK ⇔ BITCLOCK (12pin)
PCM_FS ⇔ LRCLOCK (35pin)
PCM_DIN ⇔ DATA OUT (40pin )
PCM_DOUT ⇔ DATA IN (38pin).
Immediately noticeable is that, due to changes on the RPi 4b, the pin 40 is now SCLK, pin 38 is now a MOSI, and pin 35 is now a MISO, while pin 12 is a PWM0. In other words, what was previously used now is labeled for another purpose. In fact, I had intended to use the MISO, MOSI, and SCLK in 35, 38, and 40 specifically, rather than 19, 21, and 23.

So, is it that these need connected the same way even on the RPi4, with the driver being setup the same, or does a change need to be made?

fmm
Posts: 3
Joined: Sun Feb 07, 2021 7:14 pm

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

Fri Sep 03, 2021 4:05 pm

Ben123 wrote:
Wed Sep 02, 2020 12:26 pm
Hello all.
Over the last month I have been working on connecting a TI ADC (tlv320adc6140) with a RPI CM3+ with mixed success. I have enabled the necessary I2C and I2S pins in the Device Tree and created a simple DT overlay. The ADC is rather new and the codec driver was only very recently released in the latest kernel update (5.8) and boasts a lot of features. The codec drivers Probe functions are called correctly and when recording with Audacity or arecord, the DAPM works and powers the appropriate parts of the ADC as expected. The driver supports the ADC as both slave or master, however both modes fail to record anything but noise.

Pins are connected as follows:
RPI - ADC
GPIO 28 (PCM_CLK) - BCLK
GPIO 29 (PCM_FS) - FS
GPIO 30 (PCM_DIN) - DOUT
GPIO 31 (PCM_DOUT) - DIN

The ADC has the option of accepting an external MCLK, however it should not be required.

When tested with an oscilloscope, with RPI as the master, a sensible BCLK and FS are generated (3MHz and 48kHz respectively), however the ADC fails to recognize the correct BCLK/FS ratio (it supports automatic clock configuration) and DOUT looks very strange.
With the ADC as master, BCLK is 2,3MHz and FS is 9kHz, however the DOUT looks better.

Here my DT overlay for running the RPI as a slave:

Code: Select all

/dts-v1/;
/plugin/;

/ {
    compatible = "brcm,bcm2835";
    
    fragment@0 {
        target = <&sound>;
        __overlay__ {
            compatible = "simple-audio-card";
            i2s-controller = <&i2s>;
            status = "okay";
            
            simple-audio-card,format = "i2s";
            simple-audio-card,name = "soundcard";
            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 = <&codec>;
            };
        };
    };

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

    fragment@2 {
        target = <&i2c0>;
        __overlay__ {
            #address-cells = <1>;
            #size-cells = <0>;
            status = "okay";
            codec: codec@4c {
                #sound-dai-cells = <0>;
                compatible = "ti,tlv320adc6140";
                reg = <0x4c>; 
                ti,gpi-config = <1 0 0 0>;
                ti,mic-bias-source = <6>; 
            };  
        };
    };
};
Here the register states (in hex) of the ADC during recording (audacity, 44.1kHz):

Code: Select all

                         REGISTER   (DEFAULT)    CURRENT
[17607.181413] PAGE_CFG (Def: 0)- Val: 0
[17607.181867] SW_RESET (Def: 0)- Val: 0
[17607.186238] SLEEP_CFG (Def: 0)- Val: 81 CHANGED!
[17607.191802] SHDN_CFG (Def: 5)- Val: 5
[17607.197158] ASI_CFG0 (Def: 30)- Val: 70 CHANGED!
[17607.201655] ASI_CFG1 (Def: 0)- Val: 0
[17607.207089] ASI_CFG2 (Def: 0)- Val: 0
[17607.211551] ASI_CH1 (Def: 0)- Val: 0
[17607.215997] ASI_CH2 (Def: 1)- Val: 1
[17607.220393] ASI_CH3 (Def: 2)- Val: 2
[17607.224770] ASI_CH4 (Def: 3)- Val: 3
[17607.229060] ASI_CH5 (Def: 4)- Val: 4
[17607.233507] ASI_CH6 (Def: 5)- Val: 5
[17607.237848] ASI_CH7 (Def: 6)- Val: 6
[17607.242169] ASI_CH8 (Def: 7)- Val: 7
[17607.246525] MST_CFG0 (Def: 2)- Val: 82 CHANGED!
[17607.251017] MST_CFG1 (Def: 48)- Val: 48
[17607.256806] ASI_STS (Def: ff)- Val: F8 CHANGED!
[17607.261455] CLK_SRC (Def: 10)- Val: 10
[17607.266818] PDMCLK_CFG (Def: 40)- Val: 40
[17607.271357] PDMIN_CFG (Def: 0)- Val: 0
[17607.276203] GPIO_CFG0 (Def: 22)- Val: 22
[17607.280803] GPO_CFG0 (Def: 0)- Val: 0
[17607.285535] GPO_CFG1 (Def: 0)- Val: 0
[17607.289972] GPO_CFG2 (Def: 0)- Val: 0
[17607.294443] GPO_CFG3 (Def: 0)- Val: 0
[17607.298821] GPO_VAL (Def: 0)- Val: 0
[17607.303255] GPIO_MON (Def: 0)- Val: 0
[17607.307648] GPI_CFG0 (Def: 0)- Val: 10 CHANGED!
[17607.312093] GPI_CFG1 (Def: 0)- Val: 0
[17607.317532] GPI_MON (Def: 0)- Val: 0
[17607.322108] INT_CFG (Def: 0)- Val: 0
[17607.326451] INT_MASK0 (Def: ff)- Val: FF
[17607.330818] INT_LTCH0 (Def: 0)- Val: 0
[17607.335555] BIAS_CFG (Def: 0)- Val: 60 CHANGED!
[17607.340093] CH1_CFG0 (Def: 0)- Val: 0
[17607.345464] CH1_CFG1 (Def: 0)- Val: A0 CHANGED!
[17607.349889] CH1_CFG2 (Def: c9)- Val: C9
[17607.355208] CH1_CFG3 (Def: 80)- Val: 80
[17607.359752] CH1_CFG4 (Def: 0)- Val: 0
[17607.364431] CH2_CFG0 (Def: 0)- Val: 0
[17607.368794] CH2_CFG1 (Def: 0)- Val: 0
[17607.373193] CH2_CFG2 (Def: c9)- Val: C9
[17607.377715] CH2_CFG3 (Def: 80)- Val: 80
[17607.382359] CH2_CFG4 (Def: 0)- Val: 0
[17607.386971] CH3_CFG0 (Def: 0)- Val: 0
[17607.391495] CH3_CFG1 (Def: 0)- Val: 8 CHANGED!
[17607.395958] CH3_CFG2 (Def: c9)- Val: C9
[17607.401199] CH3_CFG3 (Def: 80)- Val: 80
[17607.405816] CH3_CFG4 (Def: 0)- Val: 0
[17607.410447] CH4_CFG0 (Def: 0)- Val: 0
[17607.414933] CH4_CFG1 (Def: 0)- Val: 0
[17607.419674] CH4_CFG2 (Def: c9)- Val: C9
[17607.424145] CH4_CFG3 (Def: 80)- Val: 80
[17607.428764] CH4_CFG4 (Def: 0)- Val: 0
[17607.433362] CH5_CFG2 (Def: c9)- Val: C9
[17607.437814] CH5_CFG3 (Def: 80)- Val: 80
[17607.442584] CH5_CFG4 (Def: 0)- Val: 0
[17607.447205] CH6_CFG2 (Def: c9)- Val: C9
[17607.452115] CH6_CFG3 (Def: 80)- Val: 80
[17607.456669] CH6_CFG4 (Def: 0)- Val: 0
[17607.461305] CH7_CFG2 (Def: c9)- Val: C9
[17607.465799] CH7_CFG3 (Def: 80)- Val: 80
[17607.470808] CH7_CFG4 (Def: 0)- Val: 0
[17607.475363] CH8_CFG2 (Def: c9)- Val: C9
[17607.479726] CH8_CFG3 (Def: 80)- Val: 80
[17607.484383] CH8_CFG4 (Def: 0)- Val: 0
[17607.488981] DSP_CFG0 (Def: 1)- Val: 1
[17607.493447] DSP_CFG1 (Def: 40)- Val: 40
[17607.497866] DRE_CFG0 (Def: 7b)- Val: 7B
[17607.502443] AGC_CFG0 (Def: e7)- Val: EC CHANGED!
[17607.507104] IN_CH_EN (Def: f0)- Val: F0
[17607.512563] ASI_OUT_CH_EN (Def: 0)- Val: 80 CHANGED!
[17607.517185] PWR_CFG (Def: 0)- Val: E0 CHANGED!
[17607.523650] DEV_STS0 (Def: 0)- Val: 0
If anyone has any ideas on what I might be doing wrong, any help is greatly appreciated,
Ben
I was able to use the tlv320adc6140 for recording using a stripped down simple-audio-card DT overlay and a separate python script that configures the ADC via I2C. The ADC board is master with an onboard clock. Here is a link to the project in case it helps: https://hackaday.io/project/179489-high ... e-learning

miro.rovis
Posts: 69
Joined: Mon Feb 08, 2021 10:31 am

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

Sat Sep 25, 2021 2:44 pm

This post is a reply to:
viewtopic.php?f=44&t=8496&start=1000#p1875362
christofer_hc wrote:
Tue Jun 08, 2021 5:24 pm
I've recently acquired a Raspberry 4 Compute Module and it's IO Board, alongside with an Auvidea B102. I'm still having problems with the sound. I've also tried to follow the manual available at the Auvidea site, didn't work for me.
I'm using the same manual, plus other, see:
Re: CM4 on CM4IO with Auvidea B102 try 2 (and try 3)
viewtopic.php?f=98&t=312563&p=1917583#p1917573
I put as much info as possible. I'm not a Linux expert though.
I haven't found some of the most important pieces of information more clearly put anywhere else than in your post (I'm not a Linux expert either).

UPDATE (a few hours later): I found it here:
Camera Serial Interface 2 (CSI2) "Unicam"
(subchapter of the Camera page)
https://www.raspberrypi.org/documentati ... si2-unicam
in bottom of that subchapter
or even closer link is to the same:
Currently supported devices
https://www.raspberrypi.org/documentati ... ed-devices
It's for B101, and tells to connect also ground, pin 8 from B101 connector to pin 39 of 40-way connector. Necessary for B102 as well?

UPDATE (3 days later): A great tip is at:
[UPDATED, SOLVED] Why "cheap" Chinese HDMI-to-CSI2 adapters (e.g.18810-1 C779) don't provide I2S sound
viewtopic.php?f=44&t=279935&p=1815663&h ... 3#p1813802
with a nice schematic and the explanation. Only missing the ground pin wire.
B102 rev 2 and B101 rev 4 have IIUC same audio connectors.

I believe I'll need your other info (later) as well, but this part cleared my doubts:
Accordingly to previous posts, I've supposed the boards should be connected like:

Code: Select all

           B102    RPI (J8)
A-DATA     5       38 (GPIO20)
A-BCK      6       12 (GPIO18)
A-LRCK     7       35 (GPIO19)
Can anyone spot something wrong here?
[...]
--
Chrístofer
I can't spot anything wrong, but if I get my setup to work, I'll revisit your topic.
Thanks for the great info (AFAICT).
Last edited by miro.rovis on Tue Sep 28, 2021 2:42 pm, edited 4 times in total.
Miroslav Rovis
www.CroatiaFidelis.hr

miro.rovis
Posts: 69
Joined: Mon Feb 08, 2021 10:31 am

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

Sat Sep 25, 2021 3:16 pm

miro.rovis wrote:
Sat Sep 25, 2021 2:44 pm
This post is a reply to:
viewtopic.php?f=44&t=8496&start=1000#p1875362
christofer_hc wrote:
Tue Jun 08, 2021 5:24 pm
I've recently acquired a Raspberry 4 Compute Module and it's IO Board, alongside with an Auvidea B102. I'm still having problems with the sound. I've also tried to follow the manual available at the Auvidea site, didn't work for me.
I'm using the same manual, plus other, see:
Re: CM4 on CM4IO with Auvidea B102 try 2 (and try 3)
viewtopic.php?f=98&t=312563&p=1917583#p1917573
BTW, could anybody confirm this is correct, or warn that it is wrong:
Image
Thanks!
Miroslav Rovis
www.CroatiaFidelis.hr

robertsonics
Posts: 8
Joined: Sun Feb 21, 2021 12:02 am

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

Wed Nov 17, 2021 2:35 am

Some progress on multichannel support using the I2S port here:

https://robertsonics.com/2021/11/17/mul ... pi-part-1/

Would welcome feedback, questions, info, etc...

phofman
Posts: 51
Joined: Mon Oct 07, 2019 1:37 pm

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

Wed Nov 17, 2021 6:59 am

Hi, very nice. This method was discussed in thread viewtopic.php?t=193550 . There is a driver in RPi kernel which implements the channel interleaving and signalling the start of audioframe via GPIO https://github.com/raspberrypi/linux/bl ... oundcard.c . Good luck with your project. BTW what FPGA do you use, if not secret? Nice work, thanks.

robertsonics
Posts: 8
Joined: Sun Feb 21, 2021 12:02 am

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

Wed Nov 17, 2021 5:01 pm

phofman wrote:
Wed Nov 17, 2021 6:59 am
Hi, very nice. This method was discussed in thread viewtopic.php?t=193550 . There is a driver in RPi kernel which implements the channel interleaving and signalling the start of audioframe via GPIO https://github.com/raspberrypi/linux/bl ... oundcard.c . Good luck with your project. BTW what FPGA do you use, if not secret? Nice work, thanks.
Thanks for the links. The driver source repo is especially interesting - I'm still learning my way around linux internals. Perhaps I can figure out how to write a driver for this.

It's not an FPGA. It's a SAM MCU - a smaller version of the one used on the SparkFun Tsunami polyphonic audio player. The SSC peripheral handles both I2S reception and TDM transmission. All done with DMA, interrupts and a very small buffer. The channel sync mechanism doesn't rely on any startup timing, but rather finds channel 1 after the protocol has started, so it's very robust.

le51
Posts: 3
Joined: Mon Feb 22, 2021 11:26 am

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

Tue Dec 07, 2021 4:11 pm

Hi
The thread mentionned by phofman is really interesting. The octo driver looks not to be the best starting point for developing your own.
The last post in the thread is from hiassofT:
If you are interested in reliable multi-channel audio via I2S then IMHO it's better to have a look at other SOCs than bcm283x which have native support for 2-8 channel audio and TDM / DSP modes in their hardware.
But, @robertsonics your work is really promising. I'm waiting for the next part !

Here are excellent and recent ressources :

* https://bootlin.com/blog/eight-channels ... h-pcm3168/

* the author, Alexandre Belloni from Bootlin has an 50 mn talk about this: it goes in depth in all that Alsa layer(s big mess ;-)

https://youtu.be/tyWYZRn2zzs

* the slides presented in the talk are here: https://bootlin.com/pub/conferences/202 ... a-asoc.pdf

robertsonics
Posts: 8
Joined: Sun Feb 21, 2021 12:02 am

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

Wed Dec 08, 2021 8:30 pm

Thanks. I'll definitely take a close look at those links.

A quick update: I got my prototype board and although there are a few patches (dumb mistakes), things are working fine. I have reliable 8 channel audio output with no channel swapping. I'm currently working on the 2 channel (stereo) input. This is also working, but I have yet to find a way to predict which 2 channels in the 8 channel alsa input buffer the audio appears. It's easy to determine after the fact because all the other channels are 0, so you just look for the non-zero data, and once you've found it, it doesn't change. But it bothers me that it's not related to the outgoing channel swap. My board has an i2C control interface and the RPi can read the outgoing TDM channel offset, and I would have thought that this would also provide a clue as to the mapping of the incoming audio data, but it's currently not the case.

I think I need to understand the relationship between the alsa playback and capture drivers and how they get started. Perhaps I'm not starting them in a way that provides reliable or predictable i2S relationship.

But this only affects input - the 8 channel output works flawlessly.
Attachments
PXL_20211208_190752368.jpg
PXL_20211208_190752368.jpg (250.39 KiB) Viewed 7431 times

robertsonics
Posts: 8
Joined: Sun Feb 21, 2021 12:02 am

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

Fri Dec 10, 2021 11:12 pm

Hoping someone here with ALSA ASoC driver experience can help clarify something. I have my multichannel I2S HAT working reliably now - see previous posts. As I mentioned, It gets around the channel swapping issue when converting I2S to TDM by coordinating known output data that identifies channel 1 with commands to the HAT using I2C. This is currently done in application code when initializing and setting up ALSA. The HAT mutes its outputs until the process is complete to prevent any of this data from reaching the outputs. The application startup process looks like this:

1) Send a reset to the HAT via I2C (this mutes the audio outputs)
2) Start the ALSA playback device
3) Start sending audio data of all 0's except channel 1
4) Tell the HAT to sync (find channel 1) via I2C
5) Start sending audio data of all 0's
6) Tell the HAT to start normal playback (unmute)

So at the moment, using this board requires that an app be written specifically to perform this initialization, or incorporate a mixer module that I've written that includes this. If I want to make this HAT generally compatible with existing linux sound applications, this initialization would presumably have to occur at the driver level.

I've been looking at the ALSA ASoC documentation, as well as at some of the existing codec, platform and machine drivers, trying to get my head around it all. What I haven't found thus far is evidence that the driver can create its own audio output data or force specific output data, or if so, where this would take place.

Would anyone be able to tell me if this is even something that a driver is capable of doing? It seems like it should be, but I haven't found the obvious driver component where this could be done.

phofman
Posts: 51
Joined: Mon Oct 07, 2019 1:37 pm

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

Sat Dec 11, 2021 6:39 am

The ASoC framework is quite complex and is being advanced constantly. IMO your best option is asking at the alsa-devel mailing list where all its development occurs.

kalimka.mira
Posts: 1
Joined: Thu Dec 23, 2021 5:35 pm

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

Thu Dec 23, 2021 5:44 pm

For me the issue was getting extremely high sample rates, without proper timestamps. I thought it was a wiring problem, but it was because of the pigpiod service which interferes with I2S Pins. Hope this helps someone facing the same issue...

mhelin
Posts: 129
Joined: Wed Oct 17, 2012 7:18 pm

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

Wed Jan 12, 2022 8:41 pm

To sync 4x number of frames using 2ch PCM/I2S channel I would rather implement some kind of protocol instead of trying to somehow using software and I2C or GPIO pins for sync. It could be as simple as using bit 0 of the 1st 32-bit word in 8 word multichannel frame to mark the beginning of the frame, bit like the Z-flag is used by Behringer in their Ultranet multichannel AES protocol. For that you would need a FPGA or CLPD though, or Pico (if you could use PIO, don't know might be possible with TDM converters).

User avatar
MikeDB
Posts: 1241
Joined: Sun Oct 12, 2014 8:27 am

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

Fri Jan 14, 2022 11:45 am

mhelin wrote:
Wed Jan 12, 2022 8:41 pm
To sync 4x number of frames using 2ch PCM/I2S channel I would rather implement some kind of protocol instead of trying to somehow using software and I2C or GPIO pins for sync. It could be as simple as using bit 0 of the 1st 32-bit word in 8 word multichannel frame to mark the beginning of the frame, bit like the Z-flag is used by Behringer in their Ultranet multichannel AES protocol. For that you would need a FPGA or CLPD though, or Pico (if you could use PIO, don't know might be possible with TDM converters).
Pico works fine. I've got 20 48 bit TDM channels at 96kHz going along a daisy chain of RP2040s using the PIOs.
Always interested in innovative audio startups needing help and investment. Look for InPoSe Ltd or Future Horizons on LinkedIn to find me (same avatar photograph)

robertsonics
Posts: 8
Joined: Sun Feb 21, 2021 12:02 am

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

Sun Jan 16, 2022 4:49 pm

mhelin wrote:
Wed Jan 12, 2022 8:41 pm
Pico works fine. I've got 20 48 bit TDM channels at 96kHz going along a daisy chain of RP2040s using the PIOs.

That certainly sounds interesting. Might you elaborate?

User avatar
MikeDB
Posts: 1241
Joined: Sun Oct 12, 2014 8:27 am

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

Sun Jan 16, 2022 5:35 pm

robertsonics wrote:
Sun Jan 16, 2022 4:49 pm
mhelin wrote:
Wed Jan 12, 2022 8:41 pm
Pico works fine. I've got 20 48 bit TDM channels at 96kHz going along a daisy chain of RP2040s using the PIOs.
That certainly sounds interesting. Might you elaborate?
I can a little, but it's a commercial product so don't want to give too much away.

RP2040 clock is set to 122.88MHz which divides down to all the necessary audio clock frequencies.
At 96kHz, this gives you maximum 1280 instructions per frame on each core.
Each RP2040 in the chain has a 96kHz frame sync, 24.576MHz clock & 4 data inputs to a PIO from the previous RP2040, and outputs the same onto the next one.
The PIOs input/output clock rate gives just enough bits for the 20 48bit channels and a few control bits left over which are sent during the frame sync pulse. If you're into audio you'll recognise the 48bits as the format the original fixed point format SHARC DSPs used which we've kept to rather than go floating point.
The PIO FIFO data is moved by the processor from input to output, allowing data to be added to or removed from any single or multiple timeslots by each RP2040.

The master 122.88MHz clock is generated on the first RP2040 with an external PLL so it can be synced to studio clock. The other RP2040s derive their clocks from their bus clock input pin which adds to the timing issues, but sending a single clock the whole length of the PCB would have been worse.

I said Pico but meant RP2040. This certainly isn't something you can build with some Picos and patch wires :-)
The PCB is carefully laid out to handle these sort of frequencies, making sure clocks don't violate the data setup and hold times. We found a 33 Ohm resistor as near as possible to each bus output minimised reflections, but you'd have to tune these to your particular PCB.
Always interested in innovative audio startups needing help and investment. Look for InPoSe Ltd or Future Horizons on LinkedIn to find me (same avatar photograph)

lucifer_rahul
Posts: 16
Joined: Thu Mar 24, 2022 6:48 am

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

Fri Apr 22, 2022 9:12 am

Hi, We are using raspberry pi board cmio4 that is hosting cm4 module from raspberry. We are trying to interface the max98089 audio codec chip with CM4 module. But so far no luck. Below is device tree overlay I am using for max98089
#include <dt-bindings/clock/bcm2835.h>
/*
* Device tree overlay for the Universal Digital Radio Controller
*/

/dts-v1/;
/plugin/;

/ {
compatible = "brcm,bcm2835";

fragment@0 {
target-path = "/";
__overlay__ {
max98088_mclk: max98088_mclk {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-names = "mclk";
clock-frequency = <50000000>;
//clock-output-names = "max98088-mclk";
};
};
};

fragment@1 {
target = <&i2s>;
__overlay__ {
clocks = <&clocks BCM2835_CLOCK_PCM>;
clock-names = "pcm";
status = "okay";
};
};

fragment@2 {
target-path = "/";
__overlay__ {
regulators {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <0>;

udrc0_ldoin: udrc0_ldoin {
compatible = "regulator-fixed";
regulator-name = "ldoin";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
};
};
};
};

fragment@3 {
target = <&i2c4>;
__overlay__ {

max98089: max98089@10 {
compatible = "maxim,max98089"/*, "maxim,max98088"*/;
#sound-dai-cells = <0>;
reg = <0x10>;
status = "okay";
clocks = <&max98088_mclk>;
clock-names = "mclk";
interrupts = <13 2>;
};
};
};

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

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

simple-audio-card,bitclock-master = <&dailink0_master>;
simple-audio-card,frame-master = <&dailink0_master>;
simple-audio-card,bitclock-slave = <&dailink0_slave>;
simple-audio-card,frame-slave = <&dailink0_slave>;

simple-audio-card,widgets =
//"Line", "Line In",
"Speaker", "External Speaker";

simple-audio-card,routing =
//"INA1", "Line In",
//"INA2", "Line In",
//"INB1", "Line In",
//"INB2", "Line In",
"External Speaker", "SPKL",
"External Speaker", "SPKR";

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

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

__overrides__ {
alsaname = <&snd>, "simple-audio-card,name";
};
};


the sound card is being recognized by ALSA. That is when I run aplay -l command I can see the below output,
root@raspberrypi:/home/pi# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: udrc [udrc], device 0: bcm2835-i2s-HiFi HiFi-0 [bcm2835-i2s-HiFi HiFi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0

Also, when I play some wav file with aplay command. I can see the clock signals on i2s clock and as well as data signal going on i2s. Also I probed the CRO on I2C lines. And there also I can see the Clock and the data signals. But still sound is not working. I am using Raspbian OS with Kernel version 5.10 I need some help with this.
The MCLK is coming from a crystal oscillator with 50MHz frequency. And I have modified the max98089 codec driver to accept 50MHz clock with prescalar value of 4.

Many thanks in advance.

phofman
Posts: 51
Joined: Mon Oct 07, 2019 1:37 pm

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

Fri Apr 22, 2022 9:25 am

IIUC your I2S controller runs in slave mode (BCLK and LRCLK signals provided by your codec clocked by the crystal master clock). I have excellent experience with DTS overlay https://github.com/AkiyukiOkayasu/RaspberryPi_I2S_Slave . But I do not use any codec kernel driver and use plain I2S with the spdif codec as a "dumb" transparent codec driver. IMO this setup is very good for initial tests as it eliminates the complexities of the codec driver in the DTS overlay. Once the I2S communication at fixed samplerate is established, the specific codec driver can be added and diagnosed.

lucifer_rahul
Posts: 16
Joined: Thu Mar 24, 2022 6:48 am

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

Fri Apr 22, 2022 9:32 am

Thanks for the reply. But the I2S is working as master here while the max98089 codec is working as slave. This is the current configuration. Then how I should proceed??
The BCLK and LRCLK signals provided by Raspberry pi I2S interface. Only MCLK is fed by the crystal clock.

lucifer_rahul
Posts: 16
Joined: Thu Mar 24, 2022 6:48 am

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

Fri Apr 22, 2022 9:48 am

phofman wrote:
Fri Apr 22, 2022 9:25 am
IIUC your I2S controller runs in slave mode (BCLK and LRCLK signals provided by your codec clocked by the crystal master clock). I have excellent experience with DTS overlay https://github.com/AkiyukiOkayasu/RaspberryPi_I2S_Slave . But I do not use any codec kernel driver and use plain I2S with the spdif codec as a "dumb" transparent codec driver. IMO this setup is very good for initial tests as it eliminates the complexities of the codec driver in the DTS overlay. Once the I2S communication at fixed samplerate is established, the specific codec driver can be added and diagnosed.
Any new suggestions??

phofman
Posts: 51
Joined: Mon Oct 07, 2019 1:37 pm

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

Fri Apr 22, 2022 9:49 am

How is synchronization of the MCLK vs. incoming I2S clocks achieved?

lucifer_rahul
Posts: 16
Joined: Thu Mar 24, 2022 6:48 am

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

Fri Apr 22, 2022 10:03 am

I think MCLK and incoming I2S clocks are not synchronized. If synchronization is required, then how to achieve this??
Currently MCLK is being fed as 50Mhz/4 where 4 is the internal prescalar for audio codec. And I2S Clock BCLK runs at 1.5MHz.

phofman
Posts: 51
Joined: Mon Oct 07, 2019 1:37 pm

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

Fri Apr 22, 2022 10:06 am

Then why not switching the codec to master and RPi I2S to slave, letting the codec generate the I2S signals (and using the linked slave DTS overlay)?

lucifer_rahul
Posts: 16
Joined: Thu Mar 24, 2022 6:48 am

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

Fri Apr 22, 2022 10:38 am

I just now tried making the Codec as master and RPi I2S as slave. By doing this the output was like when I try to run the aplay command the output is stuck(hangs) at
Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono . Could you please tell what could be causing this? And still no output from speaker.

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