Linux ALSA device tree bindings for 3 x ADAU1761 and 2 x SAI

Hi Rolf,

Unfortunately I think that simple card driver is not flexible enough to accommodate such a particular case with multiple codecs attached to same DAI.

Especially as you correctly stated that widgets/routing part where we have the same names for routes in codec drivers so we can't really address say Headphones out of codec 1/2/3.

I think that you have to write a custom ALSA machine driver for this setup.

Also please post a question on alsa-devel mailing list describing this setup so that Alsa specialists will answer you there.

Regards,

Bogdan

Hi Bogdan,

Ok. Thank you for your reply.

I will re-post in alsa-devel mailing list.

By chance we came across a reply to a posting stating the following:

"Unfortunately the ADAU1761 serial ports do not go to high impedance
when unused channels are being output. The output line is driven at all
times"

Is this correct ? If so we will need to re-design our hardware ..

Regards

Rolf

Hello Bogdan,

I support the ADAU1761 part and it is correct that it does not tri-state during unused slots. If you use the DSP in the part rather than just use it as a codec, then you can daisy chain the serial ports and have each part add its signal onto the TDM buss and send the incoming data out onto another channel so you end out with one TDM stream with 8 channels of data. The data would then have to be time aligned by the receiving processor. This would require loading in a DSP program into the device. I do not know if the driver is setup for that at all. 

So another choice is a hardware change. The ADAU1372 should have a Linux driver available. That part is a newer part and so the serial port is more flexible and can tri-state during unused TDM slots. When using this feature you cannot use the CLKOUT pin because there is a known bug. The CLKOUT signal is gated when the TDM slot is tri-stated. That is usually not an issue since I would not expect you to need that clock output. 

The big plus about this device is that there are ASRCs on the serial ports. So the converters run at a higher rate for lower latency and then is decimated down. The ASRC allows the codec to be on its own clock domain and the ASRC will simply follow the incoming sample rate. This is handy when switching to other signal sources and sample rates. There is no need to write to the codec to change the sample rate, it will do it automatically. 

If your I/O needs are greater there may be other options. Fill me in on your application.

Dave T

Hello Dave,

Ok. Thank you for your reply. I have had a look at ADAU1372 but it is not pin compatible, and has no DSP. Additionally the bug you mentioned excludes it for our use. So we will stick with the ADAU1761. We are planning on solving the lacking tri-stating by using an OR gate provided that the ADC data line is guaranteed to always be driven low outside each ADAU's allocated time-slots. Do you think this will work?

Rolf  

Hello Dave,

Ok. Thank you for your reply. I have had a look at ADAU1372 but it is not pin compatible, and has no DSP. Additionally the bug you mentioned excludes it for our use. So we will stick with the ADAU1761. We are planning on solving the lacking tri-stating by using an OR gate provided that the ADC data line is guaranteed to always be driven low outside each ADAU's allocated time-slots. Do you think this will work?

Rolf  

Hello Rolf,

Most people who use the 1761 with Linux do not use the DSP. They only use it as a codec. There are other parts that will have a DSP but nothing will be pin compatible. Then the CLKOUT bug is surprising that you would be using it. Again, in Linux based systems there is usually other master clock sources for the system so I am glad I mentioned it.

Your OR gate solution might work. It will depend on how fast the gate can react and bring up the line. I am pretty certain the ADC will output zeros in the unused slots. I would have to check that but you can easily look at it on a scope as well.  This also means that the OR gate would be for all the data in every slot. If the timing is too slow then flipping the polarity of the bit clock on the receiver might give you more margin on the data timing. Something to experiment with. 

This solution is certainly something that has to be tested and look at the timing on the gate's datasheet to see how it will behave over temperatures and silicon skews. Then see what margin you are seeing at room to get an idea if it will work for all conditions. 

Dave T