I am using a ADAU1372 codec at a sample frequency of 16 kHz and from measurements I found that a frequency of 8.1 kHz at the ADC input appears only 6 dB lower at 7.9 kHz at the ADC output (when compared to signals < 8 kHz) and that a signal of 7.9 kHz at the DAC input appears as two signals at the DAC output at 7.9 kHz and 8.1 kHz only 6 dB lower.
I would expect that an digital anti-aliasing filter was in place of at least - let's say 40 dB, but obviously that is not the case.
I am doing something wrong? Is there a setting to enable a digital anti-aliasing filter for a 16 kHz sample frequency?
If no, then does Analog Devices have a codec with similar requirements (sound quality, latency, power consumption) but with an anti-aliasing filter for a sample frequency of 16 kHz (possible alternatives: 24 kHz or 32 kHz)?
I can work around the problem by using the sample frequency of 48 kHz (or higher), which has a good anti-aliasing filter according to the specifications, and implementing my own sample rate converter with digital filter, but I prefer to have this done by the codec.
Ad van de Voort
What is the master clock input to the codec? What do you have the PLL set to and the dividers after the PLL set to?
Then what is the sampling rate of the ADC set to?
I am still confused about the ADAU1372 specifications (D12702-0-12/14(0) Rev 0). Table 6 suggests this codec has proper anti-alias filters:
but Figure 36 shows that for Fs = 192 kHz and LRCLK = 48 kHz the filter pass band goes up to 24 kHz:
This figure 36 corresponds with my measurements:
This filter does not prevent aliasing in the range 20 kHz to 28 kHz, which might be OK since it is meant for audio applications in frequency range 20 Hz to 20 kHz.
For Fs = 192 kHz and LRCLK = 16 kHz the filter pass band goes up to 8 kHz:
This gives aliasing in the range 6.7 kHz to 9.3 kHz, which is not acceptable for audio applications.
What is the typical application for LRCLK < 48 kHz? What is the design idea behind it?
Hello Ad van de Voort,
I would agree that the filter is not aggressive enough and the cutoff at Nyquist should be deeper. They are designed for low latency but if I were designing it I would have started rolling off earlier. I am not certain exactly why they did it the way they did it. This part was designed just before I started working here.
The part was originally designed for use in applications like headphones and speakerphones etc. In those applications the sampling rates can be much slower. Bluetooth rates are often 8kHz. High bandwidth SKYPE calls are 16kHz fs. What is great about this part is that it can operate in its own clock domain since the serial ports are all going through the sample rate converters. If they are operated as a slave then they will simply follow whatever the sample rate of the serial clocks. (within reason and within the frequency specs of the part of course). So for applications like Bluetooth or communications coming from a network, the clocks will drift and cannot operate as a slave so this codec can operate as a slave and follow the incoming rate.
So what is your application? There may be other parts that are better suited for you. What are your expected volumes for production?
Thanks for your answer. The application for the codec is a mobile hearing aid that is carried like a smart phone with wires to a headset that has ear phones and microphones. The expected volume is still unknown as we will test the prototype first, but if the user test is successful the expected volume might grow to something like 10,000.
- two DAC outputs, at least two ADC inputs but preferably more: 4 or 6
- flexible sample rate of 16 kHz and 24 kHz, no requirements for asynchronous sample rate conversion
- anti-aliasing filters
- good sound quality: noise + THD better than 90 dB
- low power consumption