ΣSigmaStudio Ask AI Русский Log in

Digital Mic input clock domain on ADAU1452.

SigmaDSP & SigmaStudio CopperMaze Dec 17, 2018 00:00 5 replies Original on forum ↗
Subscribe
CopperMaze Question
Dec 17, 2018 00:00

Hello everyone,

I have a question about clock domain for digital mic input.
I will use a distant microphone on a measurement system and wish to us a PDM Mic to optimise cable costs (2 pairs of "numeric" audio instead of 3 for i2s, and doesn't need a DAC like an analog mic).

The cable length I need to have (and consequent propagation time) doesn't allow me to send the clock from the DSP, and forces me to generate it at the microphone side. I think this will also be better for the sound, lowering jitter, and having a clock source closer to the delta sigma. I plan to use a 3.072Mhz clock meaning the microphone clock and the DSP clock will be very close (48kHz), but not synchronous. I could send a clock from the DSP and then back from the microphone. That would allow to have the same clock for the DSP and microphone, AND having both the PDM Data and Clock arriving at the same time at the DSP inputs. But I prefer to avoid this because it would cost one more pair of cable, more lvds, and increased jitter at the microphone etc...

So my question is: Would the PDM mic input work with this asynch slave clock (BCLK_INx)? Do I absolutely need to use an ASRC ? Will the ASRC work correctly with sampling frequencies that close to each other ?

Greetings,
BRR

Edit Notes
clarification2

[edited by: CopperMaze at 9:31 PM (GMT 0) on 17 Dec 2018]

Audio Signal Processors

adau1452

clock domain

digital microphone

SigmaDSP Audio Processors

DaveThib Reply
Dec 17, 2018 00:00

Hello BRR,

You will not be able to use the PDM input with an external clock. You must use the clock from the DSP. My suggestion is to use a digital mic that puts out I2S. Then you will be able to use the ASRC on the DSP and operate the port as a slave.

Dave T

CopperMaze Reply
Dec 17, 2018 00:00

Hi Dave,

Thanks for the quick answer.
I joined a screenshot of an ASRC config where Mic inputs seems to be connected without passing by the core dsp. I see that the ASRC only accepts Serial INs as "feeds", and accepts Mic INs as Source. Are the Mic INs in the source drop down refering to the ASRC output in the DSP Core ? SigmaStudio is really confusing sometimes.
Also, I don't understand where is the limitation exactly. Do you have more details ?

-BRR

ROUTING_MATRIX_ASRC.png
ROUTING_MATRIX_ASRC.png
CopperMaze Reply
Dec 20, 2018 00:00

Okay, quick follow up.

Everything in the datasheet and in Sigma Studio looks like it would be possible to feed a PDM mic with an asynchronous clock in the DSP Core passing by an ASRC, except this:

A bit clock pin from one of the serial input clock domains

(BCLK_INx) or one of the serial output clock domains (BCLK_

OUTx) must be set up as a master clock source, and its output

signal must be connected to the PDM microphones to provide

them with a clock.

(from the ADAU1452 datasheet)

It looks like PDM Inputs decimators are hardwired to the master clock, or are maybe even run in the DSP Core. Could also be the GPIOs that have no direct path to the decimator. Or (surely) both haha.

Well, back to the drawing board.

DaveThib Reply
Dec 21, 2018 00:00

Hello CopperMaze,

You found the section of the datasheet that I was going to point out. The timing is very important with a PDM signal so I think the designers wanted a system that was dependable and so chose to implement it so it had to be a master. I would have to ask and I might not get the complete answer but the fact is you need to use the clock from the DSP.

I do suggest you look into a mic that outputs I2C. Another option for you is to use the ADAU7002. It is a PDM to I2S converter. It is a tiny little part and works great. The only detail is that it is a tiny little part so if you are not prepared to use wafer level parts then that can be a problem. It takes very low power and since it is so small it can be mounted near the mic on a small PCB. How it works is that you feed it I2S signals (it is always a slave) and then it converts those clocks to produce the PDM clocks to drive the mic. Then you can run the I2S a little longer but not too long. My suggestion is to operate it at a lower sampling rate to give plenty of timing margins on the clocks and then run it into an ASRC on the DSP. This would be fine if you are only interested in voice pickup. Obviously music would not be good to have at a lower rate.

Oh, one comment about your earlier post about the ASRC settings. I would love to edit that GUI with the settings. It is not clear. The ASRC source is just that, choosing the source of data and clocks. If you choose "Serial Ports" as a source then the upper box selecting the channel is relevant. If you do not choose "Serial Ports" then the upper selection box for the "feed" is not doing anything. The picture really should have them cascaded and greyed out when serial ports is not selected. Then it would be more intuitive.

Dave T

CopperMaze Reply
Dec 21, 2018 00:00

Hi Dave,

Yes some improvements in Sigma Studio would be great. But, well, in the end there is almost always a way to figure out what is what with the datasheets. It does the job . But it would really be great if you could release a compiler for the SigmaDSPs.

I saw the ADAU7002, nice part indeed. It wouldn't work in my case because it takes its clock from the I²S input on the DSP side. So we are back to almost the same timing problem.

I could use more pairs, but I need to keep the cable cost of my final product very low. I am limiting the cable connecting the mic unit to the main unit to cat5e. They are cheap, standard, readily available, and have great performance with LVDS under 10 Mhz. I'm limited to 2 pairs for digital audio, because one pair is used for power supply, and the other for low speed I²C.

Back to the PDM input. The only problem I have with this cable is the propagation time. If the clock is send from the DSP, the PDM bit stream will come back delayed in respect to that clock. The bit stream could be delayed by an arbitrary time and will still be processed correctly as long as the right timing is shown at the DSP input. I mean, the rate is okay, I just don't know when the signal will come back to the dsp, and I just need the timing to be right, and the stream can be delayed as long as I want. Sounds like some signal conditionning might do the trick.

I will stick to analog mics for now. The signal should be okay on one pair with a high current differential loop. But well, I need analog drivers and an additional ADC, raising costs a little bit. On the good side, it will be more flexible. There are more analog mics out there than PDM mics.