Change mux input based on last active input

Hello Audrey,

Bob has done an awesome job helping you get this sorted out as he usually does. I just want to jump in and comment that since you plan on using the serial port with several different sources, I have to ask about clocking? Will all of these sources be using the same master clock that the 1701 is using? If it is not then you will have issues with either the audio muting and cutting in and out or no audio at all. The part has a strange behavior that if you send it clocks based from a different master clock but you are just listening to the on-chip ADC it will still mute the audio. 

Since I think you most likely are using sources that are not synchronous, you really should be using the ADAU1452 platform that has ASRCs built in. The only down side is you will have to include a codec for your local analog signal. 

Dave T

Hey Dave,

Thank you for the input. Unfortunately I can find no alternative to the setup I am planning to use (Wondom/sure audio JAB5 + APM2) with ADAU1452. If there was any way to use it, I would. If you know of any similar hardware which is readily available I am all ears 

The APM2 handles input switching and equalization, then passes I2S out to the JAB5 for active crossover and amplification.

I intend to use two TOSLINK / SPDIF to I2S cards, both in slave mode, along with an XMOS asynchronous USB to I2S board, which will provide MCLK. All 1701s will be run in slave mode, and all hardware will recieve MCLK from the XMOS board. I will be using the ADCs of one 1701 for analog input. Will I have any issues with this?

Thank you 

Hello IAmAudry,

This is a complicated setup and I think the ADAU1452 would handle all the switching, EQ and crossover needs. I would still have to have a better understanding of the entire system to give any further advice. But, this would require you to design your own hardware and it seems like you are looking to purchase hardware parts to put together a system. The XMOS board may be the glue to hold all this together. Using the MCLK from the XMOS is good. So I think you will probably be fine. You may get some clicks or pops when switching from one source to another if the MCLK has to change but it most likely will not be too bad and if you can implement a mute while the switching is happening you will be fine. 

I just commented on a problem that I saw coming up if things were not on the same master clock. 

Dave T

Hi Dave,

Yeah I am aware that the ADAU1452 is a massively better solution. Maybe in the future I might be able to put together my own board, but I want to start slow and with readily available hardware.

I am still wrapping my head around the I2S protocol and wiring - can you shed any light on this problem?

Say I am using an ADAU1701 to take input from two I2S slave devices (my SPDIF boards), and one Master device (my USB card).

As per this table in the datasheet, the INPUT_LRCLK/BCLK ports function only in slave mode - as such, I would need to provide an external LRCLK, BCLK, and MCLK - these clocks come from the Master I2S device, which is the XMOS board in this case.

I would wire LRCLK, BCLK, and MCLK from the master device to all slaves (including 1701), then connect the data lines of each source board to its own individual SDATA pin. This would allow me to "listen" to all i2s sources simultaneously, and pick and choose which one to output using my program as seen above. Do I have this right?

Hello,

I can appreciate your approach of taking things one step at a time. People always learn in layers, a bit more detail with each layer. 

As far as the connections to the 1701 you are correct. You can take the clocks supplied by the XMOS board and send it to all the devices and then they will send their audio based on the clocks. Then the audio will show up on the digital section of the input cell, inputs 2-9. 

What I have difficulty seeing that this solution will work is this:

SPDIF inputs the clock is from the remote source and is recovered from the SPDIF stream. There is no way to slave an SPDIF receiver. Unless you are in a broadcast facility where everything in the building is running on house sync. Then a USB source is the same thing. It is the computer's internal clock and cannot slave to external clocks. 

With an SPDIF board, you will have an SPDIF output so in that case it can slave to the incoming clocks and send that out of the SPDIF transmitter. Now it comes down to the device on the other end, if it can slave to the incoming SPDIF clocks and use that to send its SPDIF data then the data being received at your SPDIF board will be in sync. I have a feeling that the device on the other end of your SPDIF board will not have that ability but I could be wrong. 

For USB I have never seen one be able to adapt to incoming clocks. So do these devices have sample rate converters? Then you are good and it will work. 

For an example on this, the ADAU1452 has an SPDIF receiver and transmitter built in. You can either run the entire system on the incoming SPDIF clocks or you have to go through the ASRC to get to the core which is the better way to go. The SPDIF TX on that part uses the internal clocks of the DSP. 

Sample rate converters really go a long way to "glue" together clocks from different signal sources and with so much audio now coming in from things like networks, the clocks are never synchronous. 

The XMOS board may come to the rescue here. If all the audio is going through that board and the switching is done there, then it will lock to the incoming clock and send out the LRCLK, Bitclock and Master clock based on the source. If you select a new source then it will lock to that source. 

Just be ready for issues like this. Hopefully, you can get it all running without too much trouble. 

Dave T

"SPDIF inputs the clock is from the remote source and is recovered from the SPDIF stream. There is no way to slave an SPDIF receiver. Unless you are in a broadcast facility where everything in the building is running on house sync. Then a USB source is the same thing. It is the computer's internal clock and cannot slave to external clocks. "

The datasheet for the chip used in my SPDIF boards seems to say otherwise unless I am misunderstanding, which is highly probable: https://www.cirrus.com/products/wm8804/

|

From what I can see here, the datasheet does say that the chip can be placed in slave mode, and will use external clocks. What I don't know is if this applies to both transmitting and receiving data.

https://www.cirrus.com/products/wm8804/

This page does say "A crystal derived, or externally provided high quality main clock is used to allow low jitter recovery of S/PDIF supplied main clocks.", which leads me to believe that this should work? I'm really not sure at this point. Is "main clock" here MCLK, or is that just an unfortunate coincidental naming issue?

Hello,

I don't have time to dig too deep into the 8804 datasheet, Some of our older eval boards use the CS8416 for SPDIF. That one can be slave or master but the clocks you feed it are only used for the TX side not the RX side. The test of the snip you provided sounds to be this is for the PLL to use but I am not certain. 

Without a sample rate converter I just do not see how it can be a slave. 

Let me describe this. If the clocks you are sending to the SPDIF are faster that the clocks coming in via the SPDIF itself, then at some point it will be asking for the next sample when it has not arrived yet. If you ask for data at a faster rate than the data is coming in then samples will be duplicated. 

The other way around, if you are pickup up samples too slowly then some of the incoming samples will missed, thrown away, because they will never be picked up in time and it will be replaced with the newest sample. 

So it is basically impossible to make the incoming SPDIF signal slave to any other clock. The clock has to be recovered and then sent to the rest of the system to play back the audio. 

Dave T

Hello,

I don't have time to dig too deep into the 8804 datasheet, Some of our older eval boards use the CS8416 for SPDIF. That one can be slave or master but the clocks you feed it are only used for the TX side not the RX side. The test of the snip you provided sounds to be this is for the PLL to use but I am not certain. 

Without a sample rate converter I just do not see how it can be a slave. 

Let me describe this. If the clocks you are sending to the SPDIF are faster that the clocks coming in via the SPDIF itself, then at some point it will be asking for the next sample when it has not arrived yet. If you ask for data at a faster rate than the data is coming in then samples will be duplicated. 

The other way around, if you are pickup up samples too slowly then some of the incoming samples will missed, thrown away, because they will never be picked up in time and it will be replaced with the newest sample. 

So it is basically impossible to make the incoming SPDIF signal slave to any other clock. The clock has to be recovered and then sent to the rest of the system to play back the audio. 

Dave T

Hi Dave,

You are absolutely right. That slave mode is only for transmitting data, I can confirm. I would need an ASRC to do this.

I've found a discrete ASRC which would cost about $70 shipped for two i2s channels, so I'm bailing on making the adau1701 work and am moving to a board like this with a 1466, which should have zero issues with sample rate conversion. https://www.aliexpress.com/item/1005001421618447.html

I greatly appreciate your input, thank you very much for your time

Audrey