Sorted, I got my card (Audio Codec Board - PROTO, WM8731) from RS component UK, and the board has a wrong crystal. I even requested a replacement, has the same problem, now think about the same batch -- made in Serbia.

Should be 12.28MHz, but has 16MHz on, the wrong crystal has component number 430..., cannot really remember, already in bin. After change crystal, everything ok.

i'm pretty new in the raspi programming and i try to connect the Adau1701 directly via i2s. I got it working with the dtoverlay=hifiberry-dacplus, but only if i uncomment the check if the hifiberry is connected to the pi and recompiled the kernel.

actually there is a codec in /linux/sound/soc/codecs/adau1701.c, is it possible to write an own devicetree overlay for the adau1701? and how can i use the codec directly?

I recently hacked the Hifiberry-DAC driver so that it would support the PT8211 16 bit stereo DAC. This works flawlessly, and it's damn easy to wire this up to the pi. I'd like to make this a real driver and contribute to rpi-linux repository. Unfortunately, when I change the name from snd-soc-hifiberry-dac.ko to snd-soc-pt8211.ko, it just refuses to work. Is this a driver tree issue? Can anybody help me? I'd like to contribute, especially since the PT8211 is so easy to work with and nice for beginners...

shahid_ce131001 wrote:hello everyone. is there possible to interface I2s Pulse Density Modulation PDM microphone through Raspberry pi as it is mentioned in peripheral interface but, i never see someone used it, and none of examples. please someone suggest some detail.
thanks

Hi,

Have you managed to solve this issue? As I am also working on a microphone with PDM output.

sibuntu wrote:hi guys
First, great great great work. Can someone give me an advice about my project. I am trying to record sound via I2S interface on Raspberry Pi model B+ with MP45DT02 http://www.st.com/st-web-ui/static/acti ... 025467.pdf. I compiled the kernel using kaolo,s blog and elinux.org site to enable i2S. But I have no success with recording yet.

Hi,

As mentioned before this is a PDM output sensor which i am also working on a similar one. Did you find a way to make the sensor operational?

I am working on a project to use both I2S TX and I2S RX of the raspberry pi at the same time and could you please kindly tell me whether this will be possible? In this echo cancellation application, I'd like to use I2S TX to send some reference signal to codec and receive the processed output from the codec through I2S RX at the same time. Meanwhile, I will use I2C/SPI to send some commands and read the status of the codec too. I know these are a lot of questions and I just start this project. Thanks very much for your kind help.

Thanks for your kind reply and it seems there are lots of mess of the kernel related driver configuration around the cirrus logic audio card. Do you think it would be possible to just use I2S and I2C without the alsa and dev tree? Thanks

i have not found a way around the device tree yet. i tried to made a device tree overlay and it compiles and installs. it's not that hard it seems.

i've been struggling with the same problem as you have. direct in direct out via I2S (no dac or adc involved). while it's quite easy to hack an existing driver it seems much harder to build one from scratch. i haven't been succesful yet. everything compiles and installs, i can modprobe my kernel modules, but aplay -l and arecord -l show fuck-all

i haven't checked the cirrus logic kernel patch, but in my experience it is necessary to get it running (it's a phenomenal device, really!!).

I2C and I2S can be enabled with simple device tree /boot/config.txt options (but this can also be done in your device tree overlay).

I'm now able to listen to music via i2s with the adau1701 by using the loader.c. Daifmt has to set to that:
.daifmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBM_CFM,

but that is not that what i want to. it is actually not so nice, that there ist no software connection between the pi and the adau1701.
There is a codec for adau1701 in /linux/sound/soc/codecs/adau1701.c, i can compile that codec and "sudo insmod adau1701.ko" the module and get it listed with "lsmod" and all that dependencies, but i won't get it running that there is is audio device in alsa.
actually, in my opinion, the adau1701 codec got everything in it for a alsa connection.
maybe there is a problem by registering the i2c device so the pi doesn't even recognize the dsp and it won't show up in alsa config. because it the raspi is "thinking" there is no adau1701.
"i2cdetect -y 1" shows me the i2c address 0x50 but the adress of the adau1701 should be 0x68.

Hi,
I have seen there are many Raspberry Pi DAC projects, I would like to create an ADC hat for the Raspberry Pi using the TI PCM4202 ADC.
The PCM4202 is hardware-controlled (no I2C/SPI, just pins up/low for selecting sample rate, format, etc.), so I have to use GPIOs for them.
So I need to write a kernel driver with available sample rates and that sets the GPIOs according to selected sample rates.
I found this as starting point:https://github.com/raspberrypi/linux/bl ... oundcard.chttps://github.com/raspberrypi/linux/bl ... ics43432.c
Is there an example for an Raspberry Pi audio driver that uses the GPIO for control?
Best regards
Stefan

...Ultranet, while proprietary, has already been reverse-engineered and determined to be 16 channels in two groups of 8 each packed into an AES3 stereo 24/192 stream and transmitted differentially over Cat5.

So, I need two differential line receivers and two AES/SPDIF decoders (something like the Twisted Pear Audio WM8804 card) which will give me dual I2S output, apparently each a 12.288MHz stream containing eight 32-bit samples at 48K. The extra byte in each sample apparently contains framing data to allow the detection of which sample is the first of the eight.

Questions:

(1) Does an RPi3 have the hardware to accept two simultaneous I2S streams?

(2) Does the driver and ALSA have the support for decoding that sort of stream as two 8-channel inputs, or perhaps even just a stereo 192 device and I can do the frame detection myself (*)

(3) Does the RPi3 in general then have enough oomph to do basic software mixing of those sixteen input channels into eight stereo output mixes and drive eight stereo output devices (naively just simple USB-to-headphone adapters).

(4) If Raspbian is too heavy, what would be a better OS? It would still need to support Wi-Fi and listening for commands in OSC format, probably from TouchOSC clients running on mobile devices.

(*) My concern here is that the frame byte might be discarded by the driver if I just let it naively accept the stream as 24/192. I might need to adapt the driver so that it checks the frame byte and inserts a sync bit into (say) the LSB of the output audio data, so that I can tell later which of the stereo samples contains channels 1 and 2. Or maybe I need to write my own driver to do all the unpacking internally and present as an 8-channel ALSA input device.

Any and all thoughts, recommendations, possible problems, flames accepted. Thanks!

I'm interested too. My application would be to make decoders to retrofit my old Mackie SA1232's to make use of Ultranet. I only need to decode a single channel, 15 for the left and 16 for the right speaker, but it would be real nice if the hardware could implement the same Ultranet passthrough that the IQ series speakers have.

simoneves wrote:Forgive the n00b questions. Hoping for a sanity check before I embark naively on a project.

I am planning a project to interface an RPi3 with my Behringer X32 digital mixing console and receive 16 channels of 48K audio over the proprietary Ultranet protocol. As described here...

...Ultranet, while proprietary, has already been reverse-engineered and determined to be 16 channels in two groups of 8 each packed into an AES3 stereo 24/192 stream and transmitted differentially over Cat5.

So, I need two differential line receivers and two AES/SPDIF decoders (something like the Twisted Pear Audio WM8804 card) which will give me dual I2S output, apparently each a 12.288MHz stream containing eight 32-bit samples at 48K. The extra byte in each sample apparently contains framing data to allow the detection of which sample is the first of the eight.

Questions:

(1) Does an RPi3 have the hardware to accept two simultaneous I2S streams?

(2) Does the driver and ALSA have the support for decoding that sort of stream as two 8-channel inputs, or perhaps even just a stereo 192 device and I can do the frame detection myself (*)

(3) Does the RPi3 in general then have enough oomph to do basic software mixing of those sixteen input channels into eight stereo output mixes and drive eight stereo output devices (naively just simple USB-to-headphone adapters).

(4) If Raspbian is too heavy, what would be a better OS? It would still need to support Wi-Fi and listening for commands in OSC format, probably from TouchOSC clients running on mobile devices.

(*) My concern here is that the frame byte might be discarded by the driver if I just let it naively accept the stream as 24/192. I might need to adapt the driver so that it checks the frame byte and inserts a sync bit into (say) the LSB of the output audio data, so that I can tell later which of the stereo samples contains channels 1 and 2. Or maybe I need to write my own driver to do all the unpacking internally and present as an 8-channel ALSA input device.

Any and all thoughts, recommendations, possible problems, flames accepted. Thanks!

I'm currently building an I2S TX driver. For now I want to do it without the Alsa layer, I just want a basic low level driver for PCM5
102. Some part of it seemed to work, the FIFO accept exactly 64 samples which is fine, but I don't know why the transmission never starts even if I enable TXON.
When I look on the PCM5102 pins I don't see any clocks (with an oscilloscop), whereas when I use the mainline driver it launch the clocks just before playing. I was expecting the clocks to be always enabled, but that's not the case so how should I start the clocks?
How to properly enable the transmission, what am I missing?

I've set the GPIO into alt0 mode, and then I start my driver. Everything that is "intern" to the raspberry pi works fine, I've the IRQ when FIFO is full or empty, I am also able to empty the FIFO when I want to.
I feel like my problem really comes from the Clocks (well I'm sure it is) since I don't see any with my driver, and Tx never starts... I'm stuck on this since 1 week, and I hope I won't spend one more on this...

Taken from the datasheet of the PCM5102:

System Clock PLL Mode
The system clock PLL mode allows designers to use a simple 3-wire I 2 S --that's what I have with my board-- audio source when driving the DAC.
The 3-wire source reduces the need for a high frequency SCK, making PCB layout easier, and reduces high
frequency electromagnetic interference.
The device starts up expecting an external SCK input, but if BCK and LRCK start correctly while SCK remains at
ground level for 16 successive LRCK periods, then the internal PLL starts, automatically generating an internal
SCK from the BCK reference. The PCM510xA disables the internal PLL when an external SCK is supplied;
specific BCK rates are required to generate an appropriate master clock.

That means that the device will give me both clocks isn't it ? Or do I have to generate the 48kHz that will be then processed to build the 1.536 MHz ?

gregeric wrote:
No, it means that if your circuit does not itself inject a clock into SCK, the PCM5102 will generate a SCK with a PLL from BCK.

BCK & LRCK are provided by the Pi's I2S peripheral when it is in master mode.

Hm, so what you're saying is that PCM5102 is the slave ? I'll try to unplug it and check BCK and LRCK pins. Because indeed if I'm wrong about the fact that the Pi has to generate is own clock, of course that explain why their's no clock when I don't start them and when I'm waiting for external clock that doesn't exist. That would explain a lot...
If that the case I don't know where & why I got so conviced about the fact that the PCM5102 was the master.

YCN-

Edit : Well you're right that the case, thanks for the suggestion you just saved me a lot of troubles ahah !! Thank you so much gregeric !

Edit : If someone needs to understand how those clocks are set (PCM_CLK and PCM_FS aka BCK and LRCK), I solved few of the issue you may fall in : viewtopic.php?f=29&t=182897&p=1161477&h ... e#p1161477 , the program is user based, but you can easily adapt it to driver space.

Last edited by YCN- on Mon May 15, 2017 7:55 am, edited 1 time in total.

Hi,
I want to connect an ADC to the I2S interface. I set up an ESP8266 to generate a I2S signal at 48kHz as master. I used this this code: https://github.com/skakri/asoc-i2s-loader and changed the format to "SND_SOC_DAIFMT_CBM_CFM", in this case the ADC will be master.
I can record at 48kHz and the signal (software generated triangle) is mostly ok, but has a few glitches (not sure if it's the ESP8266 or the RPi). If turn the ESP8266 off, I cannot record (time is not running), that is how it is supposed to be, because RPi is slave. But when I select 22050Hz as record sample frequency it stops after about 0.5s. Isn't it supposed to just assume the signal from the ESP is 22050Hz no matter what the frequency actually is?
Best regards
Stefan

Note: I updated Raspbian (kernel was updated too), rebuild module and now it works just fine

What do I have to do to get my own driver working?
I used the Hifiberry DAC driver as a starting point, because it uses the PCM5102, which is also a H/W controlled like the PCM4202.
The modules compile & load just fine, but the rpi-4202-adc does not depend on the pcm4202 (it should be depending on it). No alsa decive is created
I attached the code. What am I missing?

Edit: Ok, found what I was missing: The device tree overlay. Again I modified the one from the Hifiberry DAC, it worked at first try. What's still missing in the driver is the control of the ADC, when samplerate is changed it has to set GPIOs correctly.

Ok, here is the driver I have written for the PCM4202 ADC.
It's design is somewhat hacky:
-The GPIO lines for H/W control are defined in a header file so you need to edit this file if you want to connect them differently before compiling. Better practice is to use the new GPIO kernel api and define GPIO device and pins in the device-overlay (I have no idea how)
-It is configured as master with a fixed clock of 24.576 MHz, so it will only support samplerates of 32/48/64/96/192 kHz, no 44.1kHz. Again, this can probably be done in a nicer way using device-overlay options.
-No DSD support (not sure if it's possible with the Raspberry Pi at all)

Feel free to improve

It will automatically configure ADC for selected samplerate and it will give "Highpass Filter" as a mixer option.
I could not yet confirm it works, I tested GPIO outputs and I2S input, but not with a real PCM4202, because I have not yet finished my board/hat.

I'm currently working on a I2S driver for 32bits 48kHz, there's something I might be missing in your code, but where do you do all the hardware part on the pi side?
I'm at that stage for now and I'll add the alsa layer later but I can't find out how the link are done? Is it only about device tree overlay ?

Hi YCN-,
this is how I understand this, my driver contains the device-overlay and two kernel modules:
The device overlay signals there is an I2S device connected that the two kernel modules are needed.
Then kernel will load the BCM I2S modules (that will handle all the I2S stuff) and the two other modules.
Module pcm4202 knows what formats/samplerates/device options are supported and how to set them.
Module rpi-4202-adc just connects the pcm4202 module to the I2S module.

If your device outputs 32 bit data, I think all you need to do is set the correct 32 bit format, here is a list of all formats supported by the linux kernel, it supports 32-bit signed/unsigned/float little/big endian:http://elixir.free-electrons.com/linux/ ... pcm.h#L143