Hi,
in my current project I'm using an ADAU1701 DSP board from Sure Electronics (~20$) in combination with the digital I²S audio output of a Raspberry Pi 2b.
I searched if there is any existing driver which fits the special requirements, but didn't find something.
Therefore I modified some existing device tree overlays and changed them to match the special conditions of the ADAU1701.
The ADAU must run as clock slave at it's I²S inputs, which wouldn't be an issue, if the Raspberry could produce the MCLK for the ADAU as well. In fact that's not possible, the Raspberry runs as clock slave. The ADAU is configured as clock master and its output bitclock and LR-clock is feed back to the input of the serial interface. As well, the clock outputs of the dsp source the clock pins of the raspberry.
I wrote a brief installation guide on my homepage: Installation Guide ADAU1701 Driver.
The files are available on Github: ADAU1701 I2S Driver Github Repo.
The installation is quite simple. No compiling is necessary.
The driver works good in combination with Raspbian. The resampling of audio material which isn't sampled at 48 kHz can be done with a short ALSA config file (due to oscillator used on the dsp - 12.288 MHz). The resampling is absolutely necessary, because the whole dsp program is compiled with a fixed sample rate and moreover the adau1701 doesn't have an ASRC. That's why a change of the sample rate during operation is not possible (like DACs configured as clock slaves or with GPIO pin to change the necessary oscillator would be able to e.g. the whole HifiBerry devices)!
I also documented the integration in the current Volumio version (2.389). The installation is nearly as easy as in Raspbian.
What makes Volumio interesting, is the opportunity to use AirPlay to stream audio content to the Pi. In combination with the possible mobile hotspot of Volumio, Airplay could be a much better mobile streaming solution as bluetooth is right now.
That's where the problem begins. The current version of Airplay (vers. 1) transmits the audio at 44,1 kHz/16 bit.
In consequence, audio must be resampled to use it with the dsp. But the Shairport-sync module is sending the audio data directly to the hardware to ensure the time stamp which is necessary for multi-room applications (as I understood so far).
I'm currently working on that issue, but my knowledge of audio linking on lower software levels is not that good. It would be nice if someone with more expertise could help.
Also people who test and give feedback would be great.
PS: I attached two pictures.
- The testing setup: Raspi 2b, Sure ADAU1701 DSP and programmer board (USBi like)
- A working screenshot of the Sigma Studio test project
Best regards,
Markus.
in my current project I'm using an ADAU1701 DSP board from Sure Electronics (~20$) in combination with the digital I²S audio output of a Raspberry Pi 2b.
I searched if there is any existing driver which fits the special requirements, but didn't find something.
Therefore I modified some existing device tree overlays and changed them to match the special conditions of the ADAU1701.
The ADAU must run as clock slave at it's I²S inputs, which wouldn't be an issue, if the Raspberry could produce the MCLK for the ADAU as well. In fact that's not possible, the Raspberry runs as clock slave. The ADAU is configured as clock master and its output bitclock and LR-clock is feed back to the input of the serial interface. As well, the clock outputs of the dsp source the clock pins of the raspberry.
I wrote a brief installation guide on my homepage: Installation Guide ADAU1701 Driver.
The files are available on Github: ADAU1701 I2S Driver Github Repo.
The installation is quite simple. No compiling is necessary.
The driver works good in combination with Raspbian. The resampling of audio material which isn't sampled at 48 kHz can be done with a short ALSA config file (due to oscillator used on the dsp - 12.288 MHz). The resampling is absolutely necessary, because the whole dsp program is compiled with a fixed sample rate and moreover the adau1701 doesn't have an ASRC. That's why a change of the sample rate during operation is not possible (like DACs configured as clock slaves or with GPIO pin to change the necessary oscillator would be able to e.g. the whole HifiBerry devices)!
I also documented the integration in the current Volumio version (2.389). The installation is nearly as easy as in Raspbian.
What makes Volumio interesting, is the opportunity to use AirPlay to stream audio content to the Pi. In combination with the possible mobile hotspot of Volumio, Airplay could be a much better mobile streaming solution as bluetooth is right now.
That's where the problem begins. The current version of Airplay (vers. 1) transmits the audio at 44,1 kHz/16 bit.
In consequence, audio must be resampled to use it with the dsp. But the Shairport-sync module is sending the audio data directly to the hardware to ensure the time stamp which is necessary for multi-room applications (as I understood so far).
I'm currently working on that issue, but my knowledge of audio linking on lower software levels is not that good. It would be nice if someone with more expertise could help.
Also people who test and give feedback would be great.
PS: I attached two pictures.
- The testing setup: Raspi 2b, Sure ADAU1701 DSP and programmer board (USBi like)
- A working screenshot of the Sigma Studio test project
Best regards,
Markus.
Attachments
I find this interesting. If one used (say) a decent XMOS USB interface instead and took MCLK from that, one could presumably run at 96kHz with the ADAU as
slave and then run some (slave) I2S DACs off the same MCLK and the jitter is then confined to the MCLK generator - is that right?
Which reduces the problem to:
- find a great stereo (USB?) to I2S with low jitter MCLK
- slave DACs
- software resampling to a fixed frequency that matches the program loaded to ADAU
It seems flexible since much of the problem is moved to software domain, and the transport is digital to output and just one clock to get right?
Is that oversimplifying?
That's correct. It's just a standard I²S transmission.
You could also use the onboard DACs of the ADAU1701.
That's right, but doesn't have something to do with this topic
This thread is about the connection of the Raspberry to the ADAU1701.
For I2S communication issues of the ADAU1701 take a look at it's datasheet.
Hello
Recently stumbled on this little device. It looks promsing to solving one piece of the project I'm working on.
But I need a few more analog outputs. So I'm thinking two of these, independent from each other, but being fed the same audio signal through I2S.
Since the clock signal is external to both the pi and the ADAU1701 (in a way..), ought it not to work?
I've never done anything with I2S, and is a little bit tired in the mind at the moment, but keep thinking it ought to work.
Your thoughts?
Recently stumbled on this little device. It looks promsing to solving one piece of the project I'm working on.
But I need a few more analog outputs. So I'm thinking two of these, independent from each other, but being fed the same audio signal through I2S.
Since the clock signal is external to both the pi and the ADAU1701 (in a way..), ought it not to work?
I've never done anything with I2S, and is a little bit tired in the mind at the moment, but keep thinking it ought to work.
Your thoughts?
If the processing power of the adau1701 is enough for your application you could easily add DACs via i2s or tdm to the dsp.
You could also use a multi dsp solution. One dsp must be the clock master for the whole system. Problem is the mclk. The output of an oscillator is mostly not build to source different chips (especially over a cable connection).
You could also use a multi dsp solution. One dsp must be the clock master for the whole system. Problem is the mclk. The output of an oscillator is mostly not build to source different chips (especially over a cable connection).
Thank you for answering! I guess it's still working and you're happy with it?
I would think that the DSP capabilities are plenty. This is for a car application. Sort of. More like a camper, but in a car form factor. Anyways.
So we have front, rear and subwoofer.
Front and rear systems are different beasts, driven by different amplifiers (under some circumstances).
So EQ for both front and rear, and if possible store a few presets that one would select somewhow.
Other than the EQ, very basic stuff such as
Crossover
HPE
LPE
again for two stereo pairs and if I could figure it out, multiple "profiles" if you'd like.
And - volume control.
Adding extra DACs sounds like a very appealing path. And I knew I'd read or seen somewhere about 8 channels. But my google-fu is failing on finding what I'd need hardware wise and some sort of schematic for how to hook it up.
There may also be a network of arduino style microcontrollers in this vehicle.
I would think that the DSP capabilities are plenty. This is for a car application. Sort of. More like a camper, but in a car form factor. Anyways.
So we have front, rear and subwoofer.
Front and rear systems are different beasts, driven by different amplifiers (under some circumstances).
So EQ for both front and rear, and if possible store a few presets that one would select somewhow.
Other than the EQ, very basic stuff such as
Crossover
HPE
LPE
again for two stereo pairs and if I could figure it out, multiple "profiles" if you'd like.
And - volume control.
Adding extra DACs sounds like a very appealing path. And I knew I'd read or seen somewhere about 8 channels. But my google-fu is failing on finding what I'd need hardware wise and some sort of schematic for how to hook it up.
There may also be a network of arduino style microcontrollers in this vehicle.
Yes I use the raspy in combination with volumio as mobile airplay streaming speaker.
If you google or use the forum search function you will find tons of info to the adau1701 and the digital IOs. Also the datasheet of the dsp is helpfull.
You can do 1x 8-channel TDM or 4x 2-channel i2s with the adau1701. There are a lot of cheap DAC boards with i2s input which run as slave. You just need to connect BCLK, LRCLK and DATA_OUT (and GND of course).
Last edited:
Does this Raspberry driver support TDM8 input + TDM8 output on the I2S-GPIOs?
My current idea for an active crossover before the AV-Receiver:
HDMI source -> HDMI Audio Extractor -> 4x I2S -> ADAU1701 -> TDM8 -> Raspberry -> HDMI Audio + black still frame video -> AV-Receiver
My current idea for an active crossover before the AV-Receiver:
Code:
FL < 300 Hz -> SL
FL > 300 Hz -> FL
FR < 300 Hz -> SR
FR > 300 Hz -> FR
C > 300 Hz -> C
C < 300 Hz -> SL + SR
LFE -> SL + SR
RL + SL < 300 Hz -> FL
RL + SL > 300 Hz -> RL
RR + SR < 300 Hz -> FR
RR + SR > 300 Hz -> RR1. That is just an audio output driver. But you can easilly add an input path with the simple card input and compile it.
2. Raspberry supports only two channels of audio (without tricks like the octo soundcard does). But it’s capable of sending the stereo channels in a tdm8 frame. I compiled overlays for generic audio out for i2s and tdm in my git repo.
3. Is that hdmi audio extractor capable of decoding formats like dolby...?
4. That workflow doesn’t seem to be very practical in general. I would either use a miniDSP which has built-in hdmi interface.
2. Raspberry supports only two channels of audio (without tricks like the octo soundcard does). But it’s capable of sending the stereo channels in a tdm8 frame. I compiled overlays for generic audio out for i2s and tdm in my git repo.
3. Is that hdmi audio extractor capable of decoding formats like dolby...?
4. That workflow doesn’t seem to be very practical in general. I would either use a miniDSP which has built-in hdmi interface.
My hope was to get bi-directional 8 channel LPCM between ADAU1701 and Raspberry with Audioinjector Octo-like tricks.
I haven't tested it, yet. I assume it does 8 channel LPCM only.
See HDMI Trennung und Extraktion von Audio 7,1 Kanal I2S/DSD/HBR/Faser/Koaxial (HDMI zu i2S/IIS)|Connectors| - AliExpress
miniDSP has abandoned HDMI
And they were in the 1k € range
Currently I have the full-range drivers connected to the AVR and the left/right woofers on the subwoofer pre-out of the AVR via an additional stereo amplifier.
It works but stereo separation isn't that good at 250 Hz crossover frequency.
98 % chance this china board doesn't decode anything. So if you want to use that chain in the home cinema and watch video material in up-to-date formats you will have problems.
Keep in mind: i2s over hdmi exists, but is far away from being a standard. If you want to use a hdmi source in combination with a dsp in diy, you have to go analog in-between (e.g. av receiver with pre-out).
Well, all that has nothing to do with the i2s driver for the raspberry, because tdm8 is not possible with standard drivers.
Last edited:
Hi Markus.Hi,
in my current project I'm using an ADAU1701 DSP board from Sure Electronics (~20$) in combination with the digital I²S audio output of a Raspberry Pi 2b.
I searched if there is any existing driver which fits the special requirements, but didn't find something.
Therefore I modified some existing device tree overlays and changed them to match the special conditions of the ADAU1701.
The ADAU must run as clock slave at it's I²S inputs, which wouldn't be an issue, if the Raspberry could produce the MCLK for the ADAU as well. In fact that's not possible, the Raspberry runs as clock slave. The ADAU is configured as clock master and its output bitclock and LR-clock is feed back to the input of the serial interface. As well, the clock outputs of the dsp source the clock pins of the raspberry.
I wrote a brief installation guide on my homepage: Installation Guide ADAU1701 Driver.
The files are available on Github: ADAU1701 I2S Driver Github Repo.
The installation is quite simple. No compiling is necessary.
The driver works good in combination with Raspbian. The resampling of audio material which isn't sampled at 48 kHz can be done with a short ALSA config file (due to oscillator used on the dsp - 12.288 MHz). The resampling is absolutely necessary, because the whole dsp program is compiled with a fixed sample rate and moreover the adau1701 doesn't have an ASRC. That's why a change of the sample rate during operation is not possible (like DACs configured as clock slaves or with GPIO pin to change the necessary oscillator would be able to e.g. the whole HifiBerry devices)!
I also documented the integration in the current Volumio version (2.389). The installation is nearly as easy as in Raspbian.
What makes Volumio interesting, is the opportunity to use AirPlay to stream audio content to the Pi. In combination with the possible mobile hotspot of Volumio, Airplay could be a much better mobile streaming solution as bluetooth is right now.
That's where the problem begins. The current version of Airplay (vers. 1) transmits the audio at 44,1 kHz/16 bit.
In consequence, audio must be resampled to use it with the dsp. But the Shairport-sync module is sending the audio data directly to the hardware to ensure the time stamp which is necessary for multi-room applications (as I understood so far).
I'm currently working on that issue, but my knowledge of audio linking on lower software levels is not that good. It would be nice if someone with more expertise could help.
Also people who test and give feedback would be great.
PS: I attached two pictures.
- The testing setup: Raspi 2b, Sure ADAU1701 DSP and programmer board (USBi like)
- A working screenshot of the Sigma Studio test project
Best regards,
Markus.
I just stumbled upon your work and tried to implement it in a project I'm working on.
For some reason when I use id with shairport -> snapcast it makes the pMiniBuffer overflow
Did you manage to get around that?
Regards
Stan
Hi Stan,
sry I did some work to make the drivers more generic (because every I2S device without config via I2C will work with the drivers). Therefore I added 4 versions of the driver:
I2S mode - Master and Slave
TDM8 mode (only two channels of audio but formated like tdm8) - Master and Slave
Now you can choose which driver you need. I haven't updated the english documentation yet (adau1701 file doesn't exist anymore). That's what I did now. Please give it a try, the driver should work now.
Regards,
Markus
Hey Markus,
I did try it and it works! Thanks a lot.
I used Shariport-Synk -> Snapcast -> adau1401 to get some wireless compatability to my speakers.
Shairport only supports 44100kHz sample rate, but the snapcast client can use alsa as player and it's easy to resample.
I only got it to work with Raspi in slave mode, the audio is a bit weird if I try to have the Raspi be the master.
Somebody developed an ESP32 client for snapcast as well (for WROVER chips with PSRAM), that I'll try to get working after the holidays.
In my case what fixed it was setting using alsa with format "48000:16:*" instead of "48000:16:2"
Regards
Stan
I did try it and it works! Thanks a lot.
I used Shariport-Synk -> Snapcast -> adau1401 to get some wireless compatability to my speakers.
Shairport only supports 44100kHz sample rate, but the snapcast client can use alsa as player and it's easy to resample.
I only got it to work with Raspi in slave mode, the audio is a bit weird if I try to have the Raspi be the master.
Somebody developed an ESP32 client for snapcast as well (for WROVER chips with PSRAM), that I'll try to get working after the holidays.
In my case what fixed it was setting using alsa with format "48000:16:*" instead of "48000:16:2"
Regards
Stan
Hello Markus!
I have been using your overlay with the rpi pi zero w which has been working fine. I recently decided to do an upgrade to the newer rpi zero w 2. In the new setup I don’t get it to work. The sound card is not recognized when doing aplay -l. Do you know if there are compatibility issues between the overlay and the rpi zero 2 w?
Br Alex
I have been using your overlay with the rpi pi zero w which has been working fine. I recently decided to do an upgrade to the newer rpi zero w 2. In the new setup I don’t get it to work. The sound card is not recognized when doing aplay -l. Do you know if there are compatibility issues between the overlay and the rpi zero 2 w?
Br Alex
Is there any paticular reason for this setup? Why not just don’t use ADAU and do your DSP on the device that sends to USB?
Will answer my own question here.
Finally I got it working on Volumio 3 setup by modifying the overlay source file to support also the Raspberry PI Zero 2 W configuration.
Modified following line in .dts file: (https://github.com/MKSounds/ADAU170...i/blob/master/generic_audio_out_i2s_slave.dts)
compatible = "brcm,bcm2708"; to
compatible = "brcm,bcm2708", "brcm,bcm2710";
Then I compiled the device tree
dtc -@ -I dts -O dtb -o generic_audio_out_i2s_slave.dtbo generic_audio_out_i2s_slave.dts
Then added the .dtbo file to /boot/overlays.
Finally I had great sound coming from my speakers.