Same i2s signal to multiple devices.

[b_force]

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?

[JS]

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

[b_force]

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

Well 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.

[ubbut]

it is certainly possible to send I2S to 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.

[JS]

I forgot to ask why? Sane signal in 4 dacs, why not one and split analog?

JS

[b_force]

I forgot to ask why? Sane signal in 4 dacs, why not one and split analog?

JS

Because 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

@ubbut
I am not mixing i2c and i2s?
But I was thinking, maybe someone could have the same question for i2c devices (for whatever reason)

[ubbut]

But I was thinking, maybe someone could have the same question for i2c devices (for whatever reason)

I2C 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.

[b_force]

But I was thinking, maybe someone could have the same question for i2c devices (for whatever reason)

I2C 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.

I 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.

[ubbut]

I just explained why it actually does makes sense.
They all have their own DSP settings, which are going to be hard programmed only once.

Yes. 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.

[b_force]

I just explained why it actually does makes sense.
They all have their own DSP settings, which are going to be hard programmed only once.

Yes. 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.

Ok, I misread that.

Well, in theory it would be possible to give them a different address first to program and after that change the address
Another 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

[ubbut]

Look at page 17 of your PDF and you'll see that each DAC has a different I2C address

[b_force]

Look at page 17 of your PDF and you'll see that each DAC has a different I2C address

Yes 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?

[bson]

Some I2C DACs support broadcast.  For example, the AD5667.

[stmdude]

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

[b_force]

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

Thanks.
I have years of experience of routing such devices.
Only never thought about the idea of using multiple slaves on one bus 

[David Hess]

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.

[b_force]

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.

Thanks, 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...

[JS]

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

[b_force]

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

To 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 

[Bassman59]

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

If 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.

[b_force]

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.

[JS]

If 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.

Still 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