Same i2s signal to multiple devices.  - Page 1
Forum section: electronics / projects

author: b_force
author_rank: Super Contributor
timestamp: July 11, 2018, 09:08:17 am
content: I was wondering if it actually would be possible to send an i2s (audio) signal to multiple devices.So sending one i2s pair (left-right) to let's say 4 DACs .Basically that means all the DACs have exactly the same output.Would it work by just simply paralleling the devices and giving them the same address?

author: JS
author_rank: Frequent Contributor
timestamp: July 11, 2018, 09:23:45 am
content: Maybe, does the adc send anything over the bus as answer?You would probably want the control bus to be independent, then I don't know how you set up the control adress and the i2c address. Or use hw control if you can.JS

author: b_force
author_rank: Super Contributor
timestamp: July 11, 2018, 09:41:48 am
content: Quote from: JS on July 11, 2018, 09:23:45 amWell in my case I am talking about i2s bus, which is audio.But I can imagine that maybe the same story counts for i2c devices?Anyway, the reason for asking is because I want to use a DAC with an integrated DSP.My signal chain would be USB -> stereo USB receiver - > DAC.The idea is to split the same signal over multiple DACs and than add the type of processing that is needed for that typical section.

author: ubbut
author_rank: Regular Contributor
timestamp: July 11, 2018, 09:43:58 am
content: it is certainly possible to send I2Sto multiple DACs. You can not however receive from multiple ADCs on only one I2S bus. Multiple I2S busses can share clock lines though.Apart from that: Not sure what you are trying to achieve, also not sure if you are mixing up I2C and I2S. They are two completely different protocols. I2S does not support addresses btw.

author: JS
author_rank: Frequent Contributor
timestamp: July 11, 2018, 09:44:20 am
content: I forgot to ask why? Sane signal in 4 dacs, why not one and split analog?JS

author: b_force
author_rank: Super Contributor
timestamp: July 11, 2018, 10:01:22 am
content: Quote from: JS on July 11, 2018, 09:44:20 amBecause the DSP is in the DAC, so each output has its own filtering specs for a specific section.Therefore I can't do an analog split.This is for a multiple way loudspeaker system.Each speaker section (high, low mid) needs to be filtered with crossovers.So it basically is the same input signal (mono audio) and needs to be divided.By sending the same i2s signal to multiple DACs I can safe a lot on the receiver side or use cheaper/easier to use receiver ICs@ubbutI am not mixing i2c and i2s?But I was thinking, maybe someone could have the same question for i2c devices (for whatever reason)

author: ubbut
author_rank: Regular Contributor
timestamp: July 11, 2018, 10:05:25 am
content: Quote from: b_force on July 11, 2018, 10:01:22 amI2C is not designed for multiple devices with the same address. It might work, but may be unreliable.In your scenario it does not make sense anyway. If you want to configure your DACs differently, they need to have different I2C addresses. Usually this is not a problem, because you can select the lower bits of the address via pins. If not I recommend using multiple I2C buses, even a soft I2C approach might be suitable.

author: b_force
author_rank: Super Contributor
timestamp: July 11, 2018, 10:08:04 am
content: Quote from: ubbut on July 11, 2018, 10:05:25 amI just explained why it actually does makes sense.They all have their own DSP settings, which are going to be hard programmed only once.After that they only need to be connected to the same audio stream basically.I am more interested if it can be done, no matter if it makes sense or not.

author: ubbut
author_rank: Regular Contributor
timestamp: July 11, 2018, 10:13:00 am
content: Quote from: b_force on July 11, 2018, 10:08:04 amYes. And usually they are programmed via I2C. So they need different addresses.I am not saying having multiple DACs on a single I2S does not make sense.

author: b_force
author_rank: Super Contributor
timestamp: July 11, 2018, 10:17:53 am
content: Quote from: ubbut on July 11, 2018, 10:13:00 amOk, I misread that.Well, in theory it would be possible to give them a different address first to program and after that change the addressAnother way is to disconnect them when programming and program them one by one.After that is all done connect them all to the same bus.So I guess you make the i2c switchable and use the i2s as multi slave?edit:A bit like this:http://www.ti.com/lit/ml/sprp527/sprp527.pdf

author: ubbut
author_rank: Regular Contributor
timestamp: July 11, 2018, 10:35:50 am
content: Look at page 17 of your PDF and you'll see that each DAC has a different I2C address

author: b_force
author_rank: Super Contributor
timestamp: July 11, 2018, 10:51:54 am
content: Quote from: ubbut on July 11, 2018, 10:35:50 amYes I have seen that.I guess it basically means that I need to figure out if my USB interface device supports multiple address.On the other hand, you still could program each device like it's not part of a chain?Or do you than get errors in the communication?

author: bson
author_rank: Unknown
timestamp: July 11, 2018, 02:57:05 pm
content: Some I2C DACs support broadcast. For example, the AD5667.

author: stmdude
author_rank: Frequent Contributor
timestamp: July 11, 2018, 03:31:54 pm
content: Point-to-multipoint I2S is certainly doable.The only thing you need keep in mind is that the BCLK (and MCLK if you have one) can at a few MHz, so you need to at least take a little care when routing them.The TLV320AIC33 can run at 96KHz sample-rate, 32bits per sample, two channels. 96000*32*2=6.144MHz

author: b_force
author_rank: Super Contributor
timestamp: July 11, 2018, 04:46:40 pm
content: Quote from: stmdude on July 11, 2018, 03:31:54 pmThanks.I have years of experience of routing such devices.Only never thought about the idea of using multiple slaves on one bus

author: David Hess
author_rank: Super Contributor
timestamp: July 11, 2018, 10:50:00 pm
content: I2S is all one way so driving multiple DACs is easy. You just need to watch out for the typical transmission line issues and I2S hardware is not designed to drive long lines so external drivers and receivers may be needed.

author: b_force
author_rank: Super Contributor
timestamp: July 12, 2018, 01:01:09 am
content: Quote from: David Hess on July 11, 2018, 10:50:00 pmThanks, yeah that's also what I just figured out.I guess a fan out/buffer would do the job, although sometimes you can get away with some series resistors.Hopefully the jitter won't get out of hand to much though...

author: JS
author_rank: Frequent Contributor
timestamp: July 12, 2018, 01:13:20 am
content: Jitter is a concern of the clock, on the i2s bus you need the bits to arrive in a reasonable time frame and let the pll lock on a clock distribution carefully selected.JS

author: b_force
author_rank: Super Contributor
timestamp: July 12, 2018, 01:20:04 am
content: Quote from: JS on July 12, 2018, 01:13:20 amTo my understanding it was always a dance between the two.So getting the clock right isn't the whole story so to speak.Or well, rather you don't want them to dance

author: Bassman59
author_rank: Super Contributor
timestamp: July 12, 2018, 03:54:55 am
content: Quote from: JS on July 12, 2018, 01:13:20 amIf the converter accepts a modulator clock input (11.2892, 12.288 MHz, and doubled or quadrupled), then jitter on the LRCLK and BCLK inputs doesn’t matter. (Jitter on the modulator clock absolutely _does_ matter!) If the converter synthesizes a modulator clock from the incoming BCLK then you want the BCLK to be within the converter’s jitter spec.

author: b_force
author_rank: Super Contributor
timestamp: July 12, 2018, 12:35:30 pm
content: Btw. Some DACs have an i2c interface next to the i2s to program volume or DSP settings.Unfortunately the i2c addresses can't always be changed.It that case a so called i2c multiplexer will be a good solution.

author: JS
author_rank: Frequent Contributor
timestamp: July 12, 2018, 01:07:34 pm
content: Quote from: Bassman59 on July 12, 2018, 03:54:55 amStill not the data, and (hopefully) you won't be generating your reference clock with other than a PLL. If you can choose a fixed sampling rate that's not a big problem, if you have a digit digital input to which you have to lock you probably want a dual loop PLL. As you already seems to know clock is everything for this.JS