DiegoCabral
Posts: 3
Joined: Tue Mar 13, 2018 11:51 am
Location: Paraguay

Re: STICKY: The I2S sound thread.

Sat Apr 14, 2018 12:48 am

HI everybody, first post here.

I connected a MEMS digital microfone accordingly to the adafruit tutorial and got the I2S communication working stereo.

I would like to read both channels and transform those information to decibels, I've reade there are two ways, convolution and FFT. Can anyone point me some libraries/codes which I could start some research on how I'll work with this data (SD) apply A-Weighting filter, transform ir to decibel, and maybe if isn't that complicated has the spectrum analyzer showing the frequencies from 0 to 20Khz. :shock:

I'm kind of lost on the whole procces as I'm graduating in electronic and telecommunication engineer but do not have a great experience in programming languages, I just know a little bit.

Thanks for the information that has been shared on this thread, it helped a lot to understand how the communication works, now it's application layer! Thanks for the help in advance. :geek:

bricolodu13
Posts: 44
Joined: Tue Aug 07, 2012 2:05 pm

Re: STICKY: The I2S sound thread.

Fri May 04, 2018 4:19 pm

Hello Hias,

I'm back with my TDA1543A.

I finally got some time to spent today to try to get correct sound out of it, but failled to do so ! :oops:

Here is my config.tx

Code: Select all

# Enable audio (loads snd_bcm2835)
#dtparam=audio=on
#dtparam=i2s=on
dtoverlay=0W1audio-soundcard,alsaname=0W1audio
Listing soundcard is ok

Code: Select all

pi@raspberrypi:~/squeezelite $ ./squeezelite -l
Output devices:
  null                           - Discard all samples (playback) or generate zero samples (capture)
  equal
  plugequal
  default
  sysdefault:CARD=GenericRJ      - GenericRJ,  - Default Audio Device
  dmix:CARD=GenericRJ,DEV=0      - GenericRJ,  - Direct sample mixing device
  dsnoop:CARD=GenericRJ,DEV=0    - GenericRJ,  - Direct sample snooping device
  hw:CARD=GenericRJ,DEV=0        - GenericRJ,  - Direct hardware device without any conversions
  plughw:CARD=GenericRJ,DEV=0    - GenericRJ,  - Hardware device with all software conversions
Playing some music is weird, I get white noise at full volume unless I play at very low level, then I can listen to the music although the quality is still not very good.

This is similar to an audio format problem

And here is the dts I used as per you post

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 = "right_j";
                                        bitclock-master;
                                        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_endpoint>;
                                        };
                                };
                        };
                };
        };

        fragment@2 {
                target = <&sound>;
                __overlay__ {
                        compatible = "audio-graph-card";
                        label = "GenericRJ";
                        dais = <&cpu_port>;
                        status = "okay";
                };
        };
};
To be sure, I also tried Left justified, exact same problem

Any idea of what I'm doing wrong here ???

Best regards,
Jean

HiassofT
Posts: 393
Joined: Fri Jun 30, 2017 10:07 pm
Location: Salzburg, Austria

Re: STICKY: The I2S sound thread.

Sat May 05, 2018 1:29 pm

Hi!
bricolodu13 wrote:
Fri May 04, 2018 4:19 pm
Playing some music is weird, I get white noise at full volume unless I play at very low level, then I can listen to the music although the quality is still not very good.
Did you maybe output audio in 24bit format? That would explain the issue.

TDA1543A is a 16-bit only DAC and because it uses right justified mode it'll look at the wrong part of the data if you feed it 24bit data (it'll use the lower 16 bits and ignore the important upper 8 bits of audio data).

With I2S, DSP and left justified modes this is not an issue as the DACs then only use the important upper bits and ignore the (not so important) lower bits.

Your overlay and seems to be just fine. I gave it a quick try and checked the signals with the scope, outputting 0xf001 on the left channel and 0x0000 on the right channel. Signals top-to-down are LRCLK, BCLK, DATA
rightj-16bclk.png
rightj-16bclk.png (8.43 KiB) Viewed 24274 times

Then I added "dai-tdm-slot-num = <2>;" and "dai-tdm-slot-width = <32>;" to the overlay, so that each sample will be transmitted with 32 clock cycles, to test if the right justified works as it should - and it did, the 16bit data was aligned to the right
rightj-32bclk.png
rightj-32bclk.png (8.45 KiB) Viewed 24274 times

so long,

Hias

bricolodu13
Posts: 44
Joined: Tue Aug 07, 2012 2:05 pm

Re: STICKY: The I2S sound thread.

Tue May 08, 2018 9:17 am

Hello Hias,

Thank you for trying to sort this out with me !

I checked again, and yes I was forcing the file to 16bits.
I also tried with aplay, as I can monitor what is going on :

Code: Select all

 :pi@raspberrypi:~ $ sudo aplay -vv -f cdr test.wav
Warning: format is changed to S16_LE
Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
Plug PCM: Route conversion PCM (sformat=S16_LE)
  Transformation table:
    0 <- 0*0.4 + 1*0.4
    1 <- 0*0.4 + 1*0.4
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 16
  buffer_size  : 22052
  period_size  : 5513
  period_time  : 125011
  tstamp_mode  : NONE
  tstamp_type  : MONOTONIC
  period_step  : 1
  avail_min    : 5513
  period_event : 0
  start_threshold  : 22052
  stop_threshold   : 22052
  silence_threshold: 0
  silence_size : 0
  boundary     : 1445199872
Slave: Plug PCM: Hardware PCM card 0 'GenericRJ' device 0 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 16
  buffer_size  : 22052
  period_size  : 5513
  period_time  : 125011
  tstamp_mode  : NONE
  tstamp_type  : MONOTONIC
  period_step  : 1
  avail_min    : 5513
  period_event : 0
  start_threshold  : 22052
  stop_threshold   : 22052
  silence_threshold: 0
  silence_size : 0
  boundary     : 1445199872
  appl_ptr     : 0
  hw_ptr       : 0
#################              +                   | 61%
And I still get this weird sound.
I changed the DAC chip to make sure, and still the weird sound.

I have ordered a shift register (74HCT164) to delay the data for 7 bits in order to try with plain I2S and make sure the DAC chip is working ok.

Thank you for your help, I'll keep you updated.
Jean

HiassofT
Posts: 393
Joined: Fri Jun 30, 2017 10:07 pm
Location: Salzburg, Austria

Re: STICKY: The I2S sound thread.

Tue May 08, 2018 11:56 am

Hmmm you seem to have an asoundrc in place that downmixes to mono. Also "-f cdr" is odd, usually you'd use "-f cd" which is S16_LE (-f cdr is S16_BE) - but I'm not sure if this has an effect when used with wav files (never tried that).

I'd start by using speaker-test and outputting directly to the hw device (which bypasses all alsalib/asoundrc conversions). eg:

Code: Select all

speaker-test -D hw:0 -c 2 -F S16_LE -r 44100 -t sine
This'll output a 440hz sine alternating on left and right channels and rule out any possible issues with the WAV file our .asoundrc setup.

To force use of S16_LE on the hw device it's best to use an .asoundrc like this:

Code: Select all

pcm.s16le {
        type plug
        slave {
                pcm "hw:0"
                format S16_LE
        }
}

pcm.!default s16le
so long,

Hias

bricolodu13
Posts: 44
Joined: Tue Aug 07, 2012 2:05 pm

Re: STICKY: The I2S sound thread.

Tue May 08, 2018 3:57 pm

Hello Helias,

Thank you very much for your help.

However, I stil get the same bad sound, unfortunately !

I also tried again squeezelite
~/squeezelite $ ./squeezelite -o sysdefault:CARD=GenericRJ -a 20:4:16:1 -s 192.168.1.13
"16" in -a 20:4:16:1 means force 16 bits

With Squeezelite I get a software volume
0 => no sound
1=> sound not weak, noisy
from around 12, the sound become less noisy but it is already very loud
20=> is close to max before the amp clips

Best regards,
Jean

bricolodu13
Posts: 44
Joined: Tue Aug 07, 2012 2:05 pm

Re: STICKY: The I2S sound thread.

Thu May 17, 2018 1:44 pm

Hello Helias,

Today I tried again, because in the mean time, I have received the 74HCT164 a shift register that I had ordered.

So here is the situation :
1/ with the I2S driver (hifiberry_dac) -> TDA1543A Sound is ok up to 30% software volume, it is around the 100% volume
2/ with the right justified driver -> TDA1543A Sound is ok up to 30% software volume, it is around the 100% volume
3/ with the I2S driver (hifiberry_dac) -> 74HCT164 ->TDA1543A Sound is ok up to 100% software volume, it is 100% volume

So now, we know the DAC is ok and we know for sure that there is something wrong in the way I implement the right justified driver.

But at least I have a solution for the time being.

Should you think at something, I would be happy to try.

Best regards,
Jean

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

Re: STICKY: The I2S sound thread.

Sat May 19, 2018 3:19 pm

Hello!

I'm right now applying a DSP to the Raspberry via I2S. I'm using a modified simple card overlay as posted a few pages before.
The DSP runs in I2S master mode and provides the clocks for the raspberry. Therefore I configured the codec to be the master.
That's the code I'm using, all needed modules get loaded successfully:

Code: Select all

/dts-v1/;
/plugin/;

// Device Tree Overlay for generic I2S audio output on Raspberry Pi

/ {
    compatible = "brcm,bcm2708";

    fragment@0 {
        target = <&sound>;
        __overlay__ {

            compatible = "simple-audio-card";
            simple-audio-card,name = "genericsoundcard";
			
            status="okay";

            playback_link: simple-audio-card,dai-link@1 {
                format = "i2s";
				
                bitclock-master = <&codec_out>;
                frame-master = <&codec_out>;

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

		                 // TDM slot configuration - BCLK ratio: 64 x Fs (2 x 32 bit) 
                                dai-tdm-slot-num = <2>;
                                dai-tdm-slot-width = <32>;
                
				};

                p_codec_dai: codec {
                    sound-dai = <&codec_out>;
                };
            };
        };
    };

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

    fragment@2 {
        target = <&i2s>;
        __overlay__ {
            #sound-dai-cells = <0>;
            status = "okay";
        };
    };
};
So the settings of the raspberry should be (please correct if false):

Codec: master mode (clocks provided from external oscillator)
Format: I2S

BCLK = 2 * 32 * Fs = 64 * Fs = 3.072 MHz
(set via dai-tdm-slot-num = 2 and dai-tdm-slot-width = 32)
LRCLK = Fs

The Settings of the DSP are:

Sample rate: 48 kHz
Bit depth: 24 bit
Data format: I2S

Clock settings:
----------------------
BCLK = 64 * Fs = 3.072 MHz
LRCLK = Fs

I2S settings:
----------------------
LRCLK polarity: falling edge (LRCLK = 0 = left channel, LRCLK = 1 = right channel)
BCLK data change: falling edge

Transmission: MSB first
MSB position: delayed by 1 BCLK

If I'm now playing a testfile (48 kHz/24 bit) the sound is badly distorted. I measured the clock outputs of the dsp, which are perfectly as they should be.
If I disconnect the clock wires from the raspberry and measure on the pins of the rpi, I can see there are clocks present as well. I'm a bit confused right now, because I declared the codec to be the clock master.
Do I have to change any settings despite of adding the overlay to config.txt ?

Best regards,
Markus.

HiassofT
Posts: 393
Joined: Fri Jun 30, 2017 10:07 pm
Location: Salzburg, Austria

Re: STICKY: The I2S sound thread.

Sun May 20, 2018 12:50 pm

MKSounds wrote:
Sat May 19, 2018 3:19 pm
I'm right now applying a DSP to the Raspberry via I2S. I'm using a modified simple card overlay as posted a few pages before.
The DSP runs in I2S master mode and provides the clocks for the raspberry. Therefore I configured the codec to be the master.
That's the code I'm using, all needed modules get loaded successfully:
If you use master configuration inside a dai-link the phandle must point to the dai subnode of the link, not to the codec node. Change the overlay like this and it should work:

Code: Select all

bitclock-master = <&p_codec_dai>;
frame-master = <&p_codec_dai>;
 
so long,

Hias

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

Re: STICKY: The I2S sound thread.

Sun May 20, 2018 4:34 pm

Hi Hias,

thank's for your tip. Works perfect now.

KanoMaster22
Posts: 196
Joined: Wed Oct 05, 2016 6:06 pm

Re: STICKY: The I2S sound thread.

Wed Jul 11, 2018 3:15 pm

Hey as some people might have seen on the forums I am currently planning a Pi Portable Recorder that I plan to use to record birdsong. Does anybody know of an board featuring an ADC, ability to add stereo mics and preferably a 3.5mm mic jack that I can use via the GPIO pins. It needs to be able to record .wav, have easily adjustable recording level (birdsong needs to peak at -6db to -12db). I am already know all about the Audio Injector boards but would also appreciate it if any has feedback on these boards - WM8731 Proto Board (https://uk.rs-online.com/web/p/analogue ... s/8829067/), Fe-Pi Audio Z V2 (https://fe-pi.com/products/fe-pi-audio-z-v2). and AudioCODEC for Mbed (https://uk.rs-online.com/web/p/analogue ... -_-7541974)

Any help is greatly appreciated,
LouisP

okenido
Posts: 85
Joined: Thu Aug 02, 2018 11:47 am

Re: STICKY: The I2S sound thread.

Thu Aug 02, 2018 12:12 pm

---
Last edited by okenido on Fri Aug 10, 2018 5:50 pm, edited 1 time in total.

bricolodu13
Posts: 44
Joined: Tue Aug 07, 2012 2:05 pm

Re: STICKY: The I2S sound thread.

Thu Aug 02, 2018 6:44 pm

Hello Hias,

Once again I'm back with this Right justified affair.
Although I made some progress with a hardware double shif register (2x X7), I still prefer to try to make everything working from the driver.

I think I'm almost done with your driver.
First of all, I had to add "dai-tdm-slot-num = <2>;" and "dai-tdm-slot-width = <32>;" to the overlay , and I had also to fix the audio data format to 16 bits and then it was working.
It looks a little bit shy though compared to what I was used to. But I should look with a scope and a code generation in linux to make objective mesurements.
So my question is, how do you write the values to the I2S (right justified) driver as per your example with the scope : "outputting 0xf001 on the left channel and 0x0000 on the right channel" ?

Thank you,
Jean

Tikkerey
Posts: 2
Joined: Thu Aug 09, 2018 1:31 pm

Re: STICKY: The I2S sound thread.

Thu Aug 09, 2018 1:55 pm

Hi people.
I'm new here.
I'm musician and I really want to have audio input and output on my raspberry.
Maybe I'm stupid, but even after reading this thread i still didn't understand is it possible to connect this board https://www.waveshare.com/uda1380-board.htm to raspberry pi.
If it is possible and someone already have done it, please give me a small tip, what should i do to get it working.

KanoMaster22
Posts: 196
Joined: Wed Oct 05, 2016 6:06 pm

Re: STICKY: The I2S sound thread.

Wed Nov 07, 2018 4:20 pm

I have done loads of research into what is the best board/chip for my project and finally decided on the WM8731. Ideally, I want to design my own PCB but I do not have any experience in designing audio boards and was looking for any open source WM8731 board for the Pi to change a bit for my use. I thought I would share with you what I only found after hours and hours of research, the I2S Audio Phat - https://github.com/skiselev/i2s_audio_phat. Big credit to the Github user skiselev for making this great board which uses the WM8731. Now I need to make one!

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

Re: STICKY: The I2S sound thread.

Wed Nov 07, 2018 8:59 pm

Hello,

I would like to connect ADC (AK5385) to i2s. The codec set as 24bit MSB justified (as per manual), instead of i2s.

I did successfully this for Amanero, that gives out 32-bit i2s. I put Pi 3B+ into slave mode, and recording with SoX was very well.
Now, is there a way to set up Pi to receive 24-bit MSB, and if yes, what should I change?

I use minimal Raspbian image for that... and not really familiar with overlays...

I used to build my_loader.c with:

codec = "snd-soc-dummy", // "dmic-codec", // -> snd_soc_dai_link.codec_name
.platform = "3f203000.i2s",
.daifmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBM_CFM,
.cpu_dai = {
.name = "3f203000.i2s", // -> snd_soc_dai_link.cpu_dai_name

And then use SoX as following:
sox -b 32 -r 192000 -t alsa hw:1 -c 2 -e floating-point -S --buffer 512000 /media/file_stereo.wav

Shall I change something in kernel again, or in syntax of SoX?

Many thanks!

HiassofT
Posts: 393
Joined: Fri Jun 30, 2017 10:07 pm
Location: Salzburg, Austria

Re: STICKY: The I2S sound thread.

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

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

Re: STICKY: The I2S sound thread.

Thu Nov 08, 2018 8:37 pm

Thank you Hias!

Here it is, page 15:
https://www.akm.com/akm/en/file/datasheet/AK5385BVF.pdf

Seems they both are right adjusted? But notice Data shift...

Sure I'd rather switch it into i2s mode, but it is soldered already in a rack soundcard, and I can't make sure this change would be safe, you know.

HiassofT
Posts: 393
Joined: Fri Jun 30, 2017 10:07 pm
Location: Salzburg, Austria

Re: STICKY: The I2S sound thread.

Thu Nov 08, 2018 10:57 pm

That's the same datasheet I was looking at.

The MSB mode is usually (and also in linux) called "left justified" because the MSB is immeadiately after the leading edge - which additional bclk padding after the LSB.

Right justified mode has it's LSB aligned before the trailing edge and optional padding before the MSB.

You either have to change the single mode pin from low to high, to get I2S mode, or have to live with occasional left-right channel swap.

so long,

Hias

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

Re: STICKY: The I2S sound thread.

Fri Nov 09, 2018 9:50 am

Thank you very much for your replies.

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

Re: STICKY: The I2S sound thread.

Fri Nov 09, 2018 12:59 pm

It was interesting though to test MSB mode, as I see I really can't switch my AKM to i2s mode, technically. AKM’s pin is grounded behind chip.

So, I re-complied Raspbian with Left Justified setting as you mentioned above.

Took Amanero, re-flashed it to LJ. Took 192-32 file and made it silent in Left channel. The idea was to play it out, looped, many times, to make sure there is nothing in Left channel in the file recorded by Raspberry.

All went perfect! For more than one hour of recording – no single sample swiped between channels, empty channel show -infinity in waveform statistics.

This is for Raspberry Pi 3B+. Wires from source to Gpio are about 10-11 cm long. Note, this was 192 khz recording (!).

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

Re: STICKY: The I2S sound thread.

Sat Nov 10, 2018 7:59 pm

P.S. MSB LJ works strange...

Mysteriously, it is incompatible with SoX: recording via Amanero (LJ) shows difference (original-recorded) in right channel. More, channels are interchanged.

At the same conditions, "arecord" work correct!!! Files are perfectly identical, channels are as supposed. Don't know the reason.

The only thing is – you really have to have XFS file system HDD to record with "arecord" tool, to prevent it from overruns.

P.P.S. With I2S though SoX and "arecord" are equal...

HiassofT
Posts: 393
Joined: Fri Jun 30, 2017 10:07 pm
Location: Salzburg, Austria

Re: STICKY: The I2S sound thread.

Sun Nov 11, 2018 6:38 pm

It's been a while since I analyzed frame sync behaviour but this sounds a lot like the channel swap I had experienced. Basically the I2S controller won' properly sync in left-justified slave mode at start.

I could reproduce this with just running arecord multiple times (and a analog source with only one channel present so it's very obvious when it occurs). Sometimes the channel were correct, sometimes they were swapped.

This swap only occurs when the first sample is immediately after the leading edge (eg in left justified and DSP mode B) and several audio codecs have the same limitation - eg the WM5102 datasheet contains the following note
The Left Justified and DSP-B modes are valid in Master mode only (ie. BCLK and LRCLK are outputs from the WM5102). These modes cannot be supported in Slave mode.
Although I knew this mode won't work well I hadn't disabled it in the driver - you'll just get a warning in dmesg that it's an unstable configuration. Maybe it's possible to get this mode stable under certain circumstances, but so far I don't know of a way to do that (it might as well be impossible).

so long,

Hias

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

Re: STICKY: The I2S sound thread.

Mon Nov 12, 2018 9:26 am

You are absolutely right.

I see it, too. Occasional channels swap with MSB and... one sample relative shift between channels. :-)

Again, thank you for your comments!

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

Re: STICKY: The I2S sound thread.

Fri Nov 16, 2018 4:49 pm

Hello,

I am building an audio setup with an I2S DAC, where I need to be able to finely tune the I2S clock speed. Therefore I built an I2C-controlled clock source to act as an external I2S Clock Master, which I connected to the bit-clk and frame-clk lines. This clock source gives me the required frequencies for both the 44.1k and 48k audio families.

Now I need to have my DAC (currently a Justboom DAC HAT) and RPi both configured as clock slaves. Unfortunately there seems to be no provision in the snd_soc_dai_link to allow this. If I do configure the RPi as a clock slave (using 'dai_fmt = SND_SOC_DAIFMT_CBM_CFM'), then the pcm512x codec driver will attempt to configure the pcm5122 DAC chip as a clock master, which will make it unable to recover its clock from the bit-clk line.

In order to overcome this, I envisioned two possibilities:

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.

2- Hack the pcm512x codec driver to have it behave as a clock slave, although required to be a master. This is what I did, albeit with the feeling of performing a dirty workaround. I then wrote an independent i2c driver for my clock source. This module gets loaded by my DT overlay, and keeps a reference to an i2c_client with its own regmap.

Now here is my problem:

In order to properly configure my clock source during audio playback, I need to pass its i2c_client reference to my snd_soc_card's 'startup', 'shutdown' and 'hw_params' functions. Therefore I need to have this reference stored somewhere in the snd_pcm_substream's private_data. But it is not clear to me how to do this, and where exactly to store this i2c_client reference. Should I further hack the pcm512x codec driver to add something like a 'clk_source' field to its private data structure? Or is there some other obvious solution I am missing here?

Many thanks for help!

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