HiassofT
Posts: 148
Joined: Fri Jun 30, 2017 10:07 pm

Re: STICKY: The I2S sound thread.

Sat Nov 17, 2018 10:51 am

Xavier_S wrote:
Fri Nov 16, 2018 4:49 pm
1- Let my clock source behave as a gateway inbetween the RPi and DAC, acting as a clock master for both sides. This involves creating a new dai_link to connect my clock source to the Justboom DAC, and then relaying information between both dai_links. Although my intuition tells me that this would be the clever way to go, I am not sure right now how to achieve this, so I didn't go that way for the moment.
This would be the easiest and cleanest solution.

In ASoC terms this is called a codec-codec link. It's often used to add in sample rate converters or DSPs into the chain.

Basically you need to create a codec driver with 2 audio interfaces. One interface is connected to bcm2835, the other one to the pcm512x. Define the number of channels, formats etc of that codec to match the ones supported by pcm512x.

When you play a stream ASoC will "negotiate" the parameters (samplerate etc) of the bcm2835-codec link with your codec but for the codec-pcm512x link you have to do it manually.

This is rather easy to do though:

In your machine/soundcard driver you define the 2 dai links, in the codec-pcm512x link you add a .params struct for the second link configuration which you set in your soundcard's .hwparams function to match the stream params.

ASoC first calls hwparams of the soundcard driver and then hwparams on all the codecs. So you don't need to do much in your soundcard driver, just define the dai links and implement the rather simple hwparams function. In your codec driver implement hwparams to setup the clock and you should be done.

Have a look at the rpi-cirrus driver (in sound/soc/bcm) how this can be implemented. The driver is rather complex but you can ignore about 95% of the code - only look at the dai link setup and hwparams where rpi_cirrus_dai_link2_params is set up.

The Cirrus Logic audio card uses 2 codecs, the first audio interface of the WM5102 is connected to the RPi, the second interface of the WM5102 is connected to a WM8804 to provide SPDIF input and output.

Although the wm5102 / arizona driver is quite a beast you can look at sound/soc/wm5102 as an example how to register multiple audio interfaces. It's not complicated, just define 2 dais with different names and ids in the snd_soc_dai_driver array that's passed to snd_soc_register_component

Edit: forgot to add, you probably don't need any I2C reference in your soundcard driver, only your codec driver needs to have that. So you can instantiate that codec driver via devicetree as usual.

so long,

Hias

Xavier_S
Posts: 5
Joined: Fri Nov 16, 2018 8:53 am

Re: STICKY: The I2S sound thread.

Sat Nov 17, 2018 2:36 pm

Thank you Hias for your very detailed response ! The codec-codec link is exactly what I was missing, I'm going to follow this path right now.
I'll keep you posted. Thanks again!

Xavier

Xavier_S
Posts: 5
Joined: Fri Nov 16, 2018 8:53 am

Re: STICKY: The I2S sound thread.

Tue Nov 20, 2018 1:28 pm

Hello Hias,

Yet another question, before I put everything on the launchpad. My soundcard driver now sits between the bcm2835 and pcm512x. It has no .controls by itself, however it has to relay all pcm512x kcontrols so that they are all made available to alsamixer.

In your rpi-cirrus driver it looks like you individually handle every one of them. Isn't there a global method to handover the whole thing at once, without having to care about every individual detail?

Thanks !
Xavier

HiassofT
Posts: 148
Joined: Fri Jun 30, 2017 10:07 pm

Re: STICKY: The I2S sound thread.

Tue Nov 20, 2018 2:26 pm

You automatically get all alsa controls from all codecs.

In the rpi-cirrus I create a bunch of additional controls, for example to expose settings and flags of the wm8804 that aren't made available by the wm8804 driver itself.

In general the soundcard driver doesn't need to contain much code, it just glues all the bits together.

so long,

Hias

Xavier_S
Posts: 5
Joined: Fri Nov 16, 2018 8:53 am

Re: STICKY: The I2S sound thread.

Wed Nov 21, 2018 10:53 pm

Ok Hias, thank you. Now comes the question of routing. My Clock Master is declared as a soundcard + codec. Therefore the codec part's snd_soc_codec_driver needs a .component_driver with .dapm_widgets and .dapm_routes. However my device, being just a clock source, has no physical contact with the i2s data. It has no real signal input/output like a DAC would have, for example.

Therefore I have a hard time figuring out what kind of input/output widget I should declare in order to be able to route something. What is your advice about that?

Thanks !
Xavier

Xavier_S
Posts: 5
Joined: Fri Nov 16, 2018 8:53 am

Re: STICKY: The I2S sound thread.

Thu Nov 22, 2018 11:55 am

Hello Hias – finally I figured out by myself. In my snd_soc_dai_driver I just had to create a .capture along with my .playback – which I had not done until now. Then I just routed .playback to .capture and voilà, it works! It is that simple. wm0010.c was a very good example for that.

Have a good day !
Xavier

VitS
Posts: 15
Joined: Wed Nov 07, 2018 8:54 pm

Re: STICKY: The I2S sound thread.

Wed Nov 28, 2018 8:07 am

I'v lost in syntax of overlays and would like to ask for a help.
I need to create a very simple overlay file for ADC codec connected to BCK/LRCR/Data, I2S format, where codec is master (Pi is slave).

I've seen Hias's post here, but it won't show record devices, only playback.
https://lb.raspberrypi.org/forums/viewt ... 8#p1397619

Appreciate any help!

HiassofT
Posts: 148
Joined: Fri Jun 30, 2017 10:07 pm

Re: STICKY: The I2S sound thread.

Wed Nov 28, 2018 12:17 pm

You have to instantiate your codec (your "ADC driver") via a devicetree fragment, the example you linked to uses the "spdif transmitter" dummy codec, so you'll only get a playback device.

Since you want to use the codec as clock master you need to use a proper driver, the (dummy) "spdif receiver" codec won't do it since it'll be missing the functionality to actually configure the codec and thus drive the clock lines with the selected rate.

There are many examples how to do this in the forum and in the RPi kernel tree, eg https://github.com/raspberrypi/linux/bl ... verlay.dts

so long,

Hias

VitS
Posts: 15
Joined: Wed Nov 07, 2018 8:54 pm

Re: STICKY: The I2S sound thread.

Wed Nov 28, 2018 12:39 pm

Thank you very much for this.

I'm not sure how to get it run as an interface? Overlay loaded OK, lsmod report as well... But aplay -l and arecord -l doesn't see it... Sorry for such a stupid questions, I must missing something very obvious...

HiassofT
Posts: 148
Joined: Fri Jun 30, 2017 10:07 pm

Re: STICKY: The I2S sound thread.

Wed Nov 28, 2018 12:50 pm

Unfortunately my crystal ball is currently in repair so I can't tell what went wrong.

Until I get it back you might help us by providing some more info: which ADC did you use, how did you wire it up, what's your DT overlay, what do you get in dmesg and vcdbg log msg (with dtdebug=1 in config.txt)?

so long,

Hias

VitS
Posts: 15
Joined: Wed Nov 07, 2018 8:54 pm

Re: STICKY: The I2S sound thread.

Wed Nov 28, 2018 1:55 pm

Got it.

PCM4202, master, i2s, 192 khz (24.576 clock). BCK LRCK DATA used, connected to GPIO as for i2s.

I've created overlay as described in your link (which look convenient), called 'cs.dtbo', added it into boot/config.txt.

vcdbg log msg:

Code: Select all

001886.140: dtdebug: Opened overlay file 'overlays/cs.dtbo'
001887.707: brfs: File read: /mfs/sd/overlays/cs.dtbo
001911.751: Loaded overlay 'cs'
001911.844: dtdebug: Found fragment 0 (offset 36)
001922.661: dtdebug: merge_fragment(/soc/[email protected],/[email protected]/__overlay__)
001922.689: dtdebug:   +prop(status)
001924.847: dtdebug: merge_fragment() end
001924.905: dtdebug: Found fragment 1 (offset 112)
001939.995: dtdebug: merge_fragment(/soc/[email protected],/[email protected]/__overlay__)
001940.021: dtdebug:   +prop(#address-cells)
001941.710: dtdebug:   +prop(#size-cells)
001943.418: dtdebug:   +prop(status)
001952.171: dtdebug: merge_fragment(/soc/[email protected]/[email protected],/[email protected]/__overlay__/[email protected])
001952.198: dtdebug:   +prop(#sound-dai-cells)
001954.019: dtdebug:   +prop(compatible)
001955.673: dtdebug:   +prop(reg)
001957.429: dtdebug:   +prop(reset-gpios)
001959.780: dtdebug:   +prop(status)
001961.636: dtdebug:   +prop(phandle)
001963.445: dtdebug: merge_fragment() end
001963.478: dtdebug: merge_fragment() end
001963.561: dtdebug: Found fragment 2 (offset 360)
001982.753: dtdebug: merge_fragment(/soc/sound,/[email protected]/__overlay__)
001982.779: dtdebug:   +prop(compatible)
001984.063: dtdebug:   +prop(i2s-controller)
001986.034: dtdebug:   +prop(status)
001987.304: dtdebug:   +prop(simple-audio-card,name)
001989.286: dtdebug:   +prop(simple-audio-card,widgets)
001991.291: dtdebug:   +prop(simple-audio-card,routing)
001993.330: dtdebug:   +prop(simple-audio-card,format)
001995.403: dtdebug:   +prop(simple-audio-card,bitclock-master)
001997.499: dtdebug:   +prop(simple-audio-card,frame-master)
002007.700: dtdebug: merge_fragment(/soc/sound/simple-audio-card,cpu,/[email protected]/__overlay__/simple-audio-card,cpu)
002007.730: dtdebug:   +prop(sound-dai)
002009.750: dtdebug:   +prop(dai-tdm-slot-num)
002011.778: dtdebug:   +prop(dai-tdm-slot-width)
002013.838: dtdebug: merge_fragment() end
002022.095: dtdebug: merge_fragment(/soc/sound/simple-audio-card,codec,/[email protected]/__overlay__/simple-audio-card,codec)
002022.128: dtdebug:   +prop(sound-dai)
002024.175: dtdebug:   +prop(system-clock-frequency)
002026.235: dtdebug:   +prop(phandle)
002027.671: dtdebug: merge_fragment() end
002027.703: dtdebug: merge_fragment() end
lsmod:

Code: Select all

[email protected]:~ $ lsmod
Module                  Size  Used by
rfcomm                 49152  4
bnep                   20480  2
hci_uart               36864  1
btbcm                  16384  1 hci_uart
serdev                 20480  1 hci_uart
bluetooth             368640  29 hci_uart,bnep,btbcm,rfcomm
ecdh_generic           28672  1 bluetooth
snd_soc_cs4265         24576  0
spidev                 16384  0
brcmfmac              307200  0
brcmutil               16384  1 brcmfmac
cfg80211              573440  1 brcmfmac
rfkill                 28672  6 bluetooth,cfg80211
snd_soc_simple_card    16384  0
snd_soc_simple_card_utils    16384  1 snd_soc_simple_card
snd_soc_bcm2835_i2s    16384  0
snd_bcm2835            32768  0
snd_soc_core          188416  4 snd_soc_simple_card_utils,snd_soc_bcm2835_i2s,snd_soc_simple_card,snd_soc_cs4265
snd_compress           20480  1 snd_soc_core
snd_pcm_dmaengine      16384  1 snd_soc_core
snd_pcm                98304  5 snd_pcm_dmaengine,snd_soc_bcm2835_i2s,snd_bcm2835,snd_soc_core,snd_soc_cs4265
snd_timer              32768  1 snd_pcm
i2c_bcm2835            16384  0
snd                    69632  5 snd_compress,snd_timer,snd_bcm2835,snd_soc_core,snd_pcm
spi_bcm2835            16384  0
uio_pdrv_genirq        16384  0
uio                    20480  1 uio_pdrv_genirq
fixed                  16384  0
i2c_dev                16384  0
ip_tables              24576  0
x_tables               32768  1 ip_tables
ipv6                  425984  30

aplay -l

Code: Select all

[email protected]:~ $ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
  Subdevices: 7/7
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
card 0: ALSA [bcm2835 ALSA], device 1: bcm2835 ALSA [bcm2835 IEC958/HDMI]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
arecord -l

Code: Select all

[email protected]:~ $ arecord -l
**** List of CAPTURE Hardware Devices ****
[email protected]:~ $ 


HiassofT
Posts: 148
Joined: Fri Jun 30, 2017 10:07 pm

Re: STICKY: The I2S sound thread.

Wed Nov 28, 2018 3:53 pm

You still seem to have the cs4265 codec referenced, which won't load until you attach a cs4265 via I2C - you have to replace that codec with the one you intend to use.

As you seem to use the PCM4202 in a fixed samplerate configuration the easiest way would be to use the (dummy) spdif receiver codec ("linux,spdif-dir" compatible string).

You just have to pay attention that you always record with 192kHz as the RPi has no way to change the sample rate. Just avoid using 44.1/48/... kHz setting and you should be fine.

so long,

Hias

VitS
Posts: 15
Joined: Wed Nov 07, 2018 8:54 pm

Re: STICKY: The I2S sound thread.

Wed Nov 28, 2018 3:55 pm

That's okay to have it on fixed rate, no problem at all, that even supposed to run so.

I thought that i2c was the reason.. How should I change it to a dummy?

Thank you!

HiassofT
Posts: 148
Joined: Fri Jun 30, 2017 10:07 pm

Re: STICKY: The I2S sound thread.

Wed Nov 28, 2018 4:02 pm

Add a fragment like this:

Code: Select all

[email protected] {
	target-path = "/";
	__overlay__ {
		spdif_rx: spdif_rx {
			#address-cells = <0>;
			#size-cells = <0>;
			#sound-dai-cells = <0>;
			compatible = "linux,spdif-dir";
		};
	};
};
and then change the cs4265 reference in the sound card fragment to &spdif_rx

so long,

Hias

VitS
Posts: 15
Joined: Wed Nov 07, 2018 8:54 pm

Re: STICKY: The I2S sound thread.

Wed Nov 28, 2018 4:37 pm

Belissimo!!!!!

Thank you, that worked well!

VitS
Posts: 15
Joined: Wed Nov 07, 2018 8:54 pm

Re: STICKY: The I2S sound thread.

Thu Nov 29, 2018 11:01 am

Something is wrong with i2s via overlay method. At least, for 192 khz recordings with 3B+.

Before I used kernel re-compilation as described in ada (with the change for CBM and CFM) – and it was fine... Now with overlay I'm getting lost frames sometimes.

I returned to that first option, with kernel, to check it up again – work perfect...

Well, I give up with overlay for my task...

UPDATED, again. Few days of recordings testing... Driver in kernel – stable for SOX.
Overlay – not: lost samples in some periods of time. For both, SOX and arecord. Tried many options, including wifi off, different parameters in config and cmdline, such as:
gpu_mem=16
hdmi_blanking=2
disable_pvt=1
force_turbo=1
elevator=noop

None of tested helped: overlay still not that stable as kernel option, doing mistakes sometimes.
Last edited by VitS on Wed Dec 05, 2018 2:37 pm, edited 1 time in total.

VitS
Posts: 15
Joined: Wed Nov 07, 2018 8:54 pm

Re: STICKY: The I2S sound thread.

Tue Dec 04, 2018 9:00 pm

Yet another question.
With the kernel driver I have only option to record in 32 bits. And 24 bits are useful, 8 other bits... rather useless – just eat space.
I would ignore those 8 and do recordings in 24 bits, but... both SOX and ARECORD in 24 bits mode gives noised/overdriven L channel and almost silent R channel, while I2S has I2S format, ADC chip has 64FS data.

Question is: how can I avoid this and do recordings in 24 bits?

// An overlay driver is fine doing 24 bits recordings, being with the same hardware environment, at the same time. But I can't rely on it here :-( //

HiassofT
Posts: 148
Joined: Fri Jun 30, 2017 10:07 pm

Re: STICKY: The I2S sound thread.

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.

Padding via bclk ratio / tdm slot with is a different thing. If you setup a codec for 24bit recording, you'll get proper data in the S24_LE format.

Note however that you usually don't want store wav files with data in S24_LE format (24 bit data in the lower 24bits of a 32bit word, upper 8 bits padding/ignored) but in S24_3LE (packed 3 bytes) format.

bcm2835-i2s doesn't support the packed S24_3LE format, only S24_LE, so eg when using arecord you have to use the (default) plughw: plugin as direct hw:0 access won't work.

For example: arecord -c 2 -f S24_3LE -r 44100 -D plughw:0 rec.wav

so long,

Hias

VitS
Posts: 15
Joined: Wed Nov 07, 2018 8:54 pm

Re: STICKY: The I2S sound thread.

Wed Dec 05, 2018 2:35 pm

I used and still use now, as most stable one (please see recent post edited above*) the one from here:

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

with changes to turn codec to master...


* viewtopic.php?f=44&t=8496&p=1400642#p1398276

xStSx
Posts: 3
Joined: Tue Dec 18, 2018 11:29 am

Re: STICKY: The I2S sound thread.

Tue Dec 18, 2018 11:46 am

Hi,
I have 2 questions, maybe a solution is pretty simple... but I got lost a little bit in all dts stuff.
Any way I got I2S working in/out 24bit,48KHz.

But..
1)
Is there any way make bclk constantly out, not only when there is some data to record/play?
I just want get 3.072MHz at bclk pin constantly.

2)
My ADC device working only as slave. So I'm feeding it with bclk and lrclk, and getting the data. But the data is 1 bclk delayed after lrclk.
How I can accomplish this delay through dts?

If I missed some options for all this , please point me :)

Thank you.

HiassofT
Posts: 148
Joined: Fri Jun 30, 2017 10:07 pm

Re: STICKY: The I2S sound thread.

Wed Dec 19, 2018 12:52 am

The bcm2835 driver seems to support SND_SOC_DAIFMT_CONT (which should also be controllable via the continuous-clock dai-link property, eg when using simple card) but I have never tested that.

SND_SOC_DAIFMT_CONT will keep the clock running during pause, but when you close the audio device it'll be stopped.

If you expereience "data shifts by one bit" you are probably using the wrong mode. In I2S mode the MSB is transmitted 1 cycle after the LRCLK change, in left-justified mode it's transmitted immediately after the LRCLK change.

so long,

Hias

xStSx
Posts: 3
Joined: Tue Dec 18, 2018 11:29 am

Re: STICKY: The I2S sound thread.

Sat Dec 22, 2018 4:56 pm

If you expereience "data shifts by one bit" you are probably using the wrong mode. In I2S mode the MSB is transmitted 1 cycle after the LRCLK change, in left-justified mode it's transmitted immediately after the LRCLK change.
You are right.. It's a specification of protocol. My bad.

And actually no need of continuous clock.
All this for working and recording digital audio of si4735.
So for now I'm starting recording, it's giving me a clock, and then I configuring the si4735 through python script.
For now it's working, just needed to test this installation.

One more question, I have measured clocks from raspberry. It's not exactly 3.072MHz (bclk) and 48.000 KHz (lrclk). My measures shows 3.071MHz and 47.998KHz.
Is there any workaround to fix the clock or it's driver and hardware issue ?

I configured si4735 for clock 32KHz (3.072MHz/96 prescaler) but it's not exactly 32KHz making si4735 be very noisy.
Thinking maybe external clock generator for bclk and lrclk it's a option. But prefers to make it only without external parts.

Thank you,
StS

HiassofT
Posts: 148
Joined: Fri Jun 30, 2017 10:07 pm

Re: STICKY: The I2S sound thread.

Mon Dec 24, 2018 12:40 pm

How did you measure the frequencies? The 48kHz measurement shows a deviation of approx 40ppm which is about to be expected.

A 3.072MHz bclk will be derived from the 500MHz PLL by using a fractional divider. Average frequency should be pretty spot on, but you may see a 2ns jitter when using a rather fast scope. This 2ns jitter shouldn't have any real-life impact though.

You can use a small trick to get a jitter-free clock derived from the 19.2MHz crystal: if you configure a bclk ratio of 80 you'll have a bclk frequency of 3.84 MHz at 48kHz sampling rate which can be derived from 19.2MHz by an integer divider of 5.

This trick doesn't work with all ADCs/DACs but according to the datasheet the si4735 should support that.

so long,

Hias

xStSx
Posts: 3
Joined: Tue Dec 18, 2018 11:29 am

Re: STICKY: The I2S sound thread.

Sun Dec 30, 2018 7:57 am

HiassofT wrote:
Mon Dec 24, 2018 12:40 pm
How did you measure the frequencies? The 48kHz measurement shows a deviation of approx 40ppm which is about to be expected.

A 3.072MHz bclk will be derived from the 500MHz PLL by using a fractional divider. Average frequency should be pretty spot on, but you may see a 2ns jitter when using a rather fast scope. This 2ns jitter shouldn't have any real-life impact though.

You can use a small trick to get a jitter-free clock derived from the 19.2MHz crystal: if you configure a bclk ratio of 80 you'll have a bclk frequency of 3.84 MHz at 48kHz sampling rate which can be derived from 19.2MHz by an integer divider of 5.

This trick doesn't work with all ADCs/DACs but according to the datasheet the si4735 should support that.

so long,

Hias
Sorry for long time to answer.

Thank you for you reply.
My setup "slightly" changed, and there is DSP now ruling the things. RaspberryPi just handling the i2c bus without all the audio stuff.

Any way I double checked, and a cause for noise wasn't clocking problem. It's just analog part missing shielding from digital part.

Thank you ;)

DanR
Posts: 15
Joined: Fri Jan 18, 2013 1:20 pm

Re: STICKY: The I2S sound thread.

Mon Jan 14, 2019 4:39 pm

Hi All,

I've produced some hardware with Video codec's on which work perfectly but the audio side is giving me tons of issues. The codec is the SGTL5000 with a 12.288MHz oscillator module connected up to i2c-1 and it can be seen at address 0x0a. I can see the i2s data reaching it and the lrclk and bclk at 44.1KHz and 1.411MHz ish but I get no sound out at all whatever I try. I've tried modifying the .asoundrc file and no nothing! dmesg shows this:

Code: Select all

[    4.103637] snd-fe-pi-audio soc:sound: ASoC: CODEC DAI sgtl5000 not registered - will retry
[    4.189512] snd-fe-pi-audio soc:sound: ASoC: CODEC DAI sgtl5000 not registered - will retry
[    4.190431] snd-fe-pi-audio soc:sound: ASoC: CODEC DAI sgtl5000 not registered - will retry
[    4.223504] snd-fe-pi-audio soc:sound: ASoC: CODEC DAI sgtl5000 not registered - will retry
[    4.227338] brcmfmac: F1 signature read @0x18000000=0x15264345
[    4.236191] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43455-sdio.bin for chip 0x004345(17221) rev 0x000006
[    4.236945] usbcore: registered new interface driver brcmfmac
[    4.237260] snd-fe-pi-audio soc:sound: ASoC: CODEC DAI sgtl5000 not registered - will retry
[    4.261596] sgtl5000 1-000a: sgtl5000 revision 0x11
[    4.283696] adv7180 0-0021: chip found @ 0x21 (bcm2835 I2C adapter)
[    4.294158] snd-fe-pi-audio soc:sound: sgtl5000 <-> 3f203000.i2s mapping ok
[    4.483138] random: crng init done
Am I to asume that the driver is working correctly despite the "CODEC CAI sgtl5000 not registered" messages? I can see the device in the audio mixer application and also in alsamixer so I would think it should work but using speaker-test to output a 440Hz sine gives nothing on my scope at all!

Any suggestions are very welcome as I have about 3 weeks until production testing is due!!

Thanks, Dan

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