Adau1761 stuttering?

Hello Gf,

I am afraid we will need a lot more info to figure this out. There could be several issues.

First will be to rule out hardware issues. It could be power supply related, timing of when you start programming the device, and how it is being initialized. So those kind of issues need to be ruled out.

Then software, ...

Are you updating parameters when often after it boots up?

Can you simplify the operation? There can be issues where a write could cause an index control to overstep its bounds and write to another parameter. This could step onto a filter and the filter can then go unstable.

So please supply us with hardware schematics and your SigmaStudio program. Then I can get more specific. Then catch the unit when the problem is present and start doing things like bypassing the digital core, bypassing some of the processing, switching to an internal oscillator, looking at levels on a meter in SigmaStudio to see if it is cutting out inside of the DSP. Start simplifying and trying to determine the extent of the issue and that will help by starting to point to something that can be the source of the problem.

Thanks,

Dave T

Hi Dave,

Let me try to answer your questions, and describe a little more in details:

From an hardware point of view, I have a MIC37100-3.3 voltage regulator (actual current is way under the specified limits for the regulator), that generates a stable 3.3v to a SoM (iMX6.ULL DART6-UL) and the codec, at the same time.

The timing of when I start programming the device, is not controlled by me, but directly by the linux Kernel, the underlying driver (official Adau drivers, by Lars-Peter Clausen), and the ALSA.

If you want I can give you a complete log of my board boot, and kernel initialization.

After boot up, I never change or update parameters. The only updates performed, are done in the boot, when the AlsaMixer restores the asound.state to the mixer.

Attached you can find my SigmaDSP studio project, and as you can see is really a basic project, no filters and effects: just the minimum required to make arecord and aplay work.

For the complete schematic, since we have a NDA with a client, I could send you a password protected zip file, if I can send you the password in a private way...

As you mentioned I'll try to tinker with the parameters once the codec starts to behave in a strange way, but since this happens really randomly and only once in a while, it won't be easy to reproduce the problem quickly.

I would like to ask you a couple of questions:

* what do you mean by "switching to an internal oscillator" ? from what i gather, reading the manual and the datasheet of Adau1761, there's no internal oscillator in the IC, am I wrong?

* since I want to be prepared for a "plan B" in case I won't be able to determine the source of the problem, and there's no Reset pin on the IC, is there a way to force a reboot of the codec, maybe through some I2C special command?

Thanks a lot for your support, really appreciated!

Gf

Hello Gf,

OK, So this makes it a little more difficult due to the complexity and abstractions that exists with the Linux interface. It would be great to be able to read the register settings when it is bad verses when it is good but that would require some external hardware I presume.

I also really wish this part had a soft reset register but it does not. You can try to call the initialization routine again but if some unexpected registers are improperly set then they will not be overwritten with new values. But, it is something to try.

There are some direct analog signal paths in this device from the analog input section directly to the analog output section. Depending on your external signal flow it is possible that you have some sort of feedback path happening which can cause this sort of cutting out signal. So should these registers that control the "talk-through" signal path be improperly set then it could case this intermittent problem. Just a guess... To verify this you would need the register dump.

Regarding the oscillator. This part has a DSP in it. There are so many things you can do with this DSP and one of them is to setup an oscillator. Thanks for providing your program it was really helpful to see it.

So this is what your DSP program is:

It is simply a pass-through program. It takes the data from the ADCs and sends it out of the serial port. Then it takes the serial input port data and sends it to the DAC. This is where you can insert anything you want.

I quickly slapped in an oscillator and connected it to all the outputs. So this oscillator will show up on the serial output port and on the DACs. Here is what the program looks like:

As you see, it is a 500 Hz oscillator and a volume control, I reduced the level by 30dB since it is a 0dBFS signal out of the oscillator. If you were using SigmaStudio then you could place some meters on the serial input ports and see the level of the signals coming in but you are not using SigmaStudio to actually program the device. I attached my program.

If you use the program you should send some audio into the ADC inputs. Not this 500 Hz signal but either music or a different frequency. This signal will not be sent out of the serial port so you should not be able to hear it anywhere. This way if the feedback path exists you will be able to hear the analog signal along with the 500Hz from the DSP.

Since it appears that you are only using this part as a codec, I suggest you bypass the DSP core altogether and use it simply as a codec. This is done with the following register settings:

As you see, I changed the serial port routing registers to not go through the DSP. The ADC outputs go directly to the serial port and the serial input port goes directly to the DACs. Now what ever is happening in the DSP will not be heard.

I was hoping the problem would be easily reproduced and not be intermittent but as usual, that is wishful thinking. It makes it difficult to know if you actually fixed the problem or not.

Let me know how this all goes.

Dave T

After a loooong debug session, we determined what the problem was, and I would like to share it so that mayeb it can be helpful to others too:

The problem was completely random and with no apparent reason. Turns out that the problem was related to the Yocto Operating System, and the ALSA process. During boot, in /etc/rc.S startup level there's a script to restore alsa mixer settings and registers in ADAU codec. But, if the DSP firmware is not yet completely loaded in the program and parameters RAM of the codec, that leads to an inconsistent state.

So the solution was to change the run level of the ALSA Restore (/etc/init.d/alsa-state), in a point where the DSP binary is completely loaded successfully (for example in /etc/rc5.d).

Now it's working flawlessly all the time.

Gf