AN02003 ASRC Aliasing issue, SPDIF receive Topic is solved

[paulvongrundan]

Hi everyone,
currently I am evaluating the XMOS ecosystem taking the first steps with the XCORE.AI multichannel audio board (XK-AUDIO-316-MC-AB).

I observe serious aliasing issues with input signals above 1 kHz when build and run the unaltered AN02003 SPDIF receive to I2S Slave Bridge with ASRC.

In order to rule out my user error as best as I can I tried the following without any success:

• all possible combinations of input and output sample rates

• upgrading the libraries from the ones that shiped with the porject to the latest versions from GitHub.

• directly monitor the I2S stream in case the eval board DAC is wrongly configured

• all other possible input formats and three different SPDIF sources (APx555, Scarlett 18i8 and UCXII)

No matter what I did, I arrived at the following results:

1kHz.jpg

The 1 kHz digital signal looks in spec and shows a very low jitter SINAD of 140 dB

5kHz.jpg

As soon as the input frequency is higher than about 3 kHz the aliasing artefacts begin to show and much worsen when you get to 20 kHz, which sounds horrible by the way.

By using a rectangle waveform as input I believe to see that there seems to be aliasing, both at the input as well as on the output of the system:

Rectangle_Aliasing.jpg

Is this a known problem or something that has been posted before, but slipped through my fingers when I searched the web?

Admittedly I am a bloody beginner on this platform...
Does anyone have a suggestion where to look in the code if the issue is actually firmware related and not my user error?

Best regards,
Paul

[Joe]

Hi,

Obviously this isn't expected so we'll look into this.

I'm not an expert on the software but I know we did see an issue with signals very close to 0dB at one point so you could try retesting at lower signal levels, I think for that issue reducing signal level to -1dB or so worked.

Cheers,
Joe

[paulvongrundan]

Hi Joe,
thank you very much for your reply and for having a look at my post. Good idea, I actually forgot to test at lower input signal levels (apart from my listening test):

Sadly, at - 20dBFS we have the same result:

5kHz_2.jpg

I did not have the time to set up the APx but it should still be clear, that the aliasing is not level dependent.
The input signal was a 5 kHz tone at -20 dBFS.

And thank you, it would be really nice if you could have a look at the code and if you could try to spot the mistake which has to be somewhere.

Best regards,
Paul

[Joe]

It could also be a setup issue potentially although I'm struggling to see how.

In your last image the signal was measuring 2.1V rms, was this from the mc audio board? In which case it would be at 0dB not -20? Or is this from an offboard dac?

Cheers,
Joe

[infiniteimprobability]

Hi,
it's possible you have run into this:

https://github.com/xmos/lib_board_support/pull/22

We moved all of the board setup code to a common library since it gets used everywhere we target that board. Recently we discovered a DAC setup issue when XMOS is the I2S slave, as it is in this app note. I'm hoping that may be the cause of the issue you are seeing and is a quick fix.

To try this, either go into the lib_board_support directory and pull the latest changes from either main or develop branch using GIT which will get you v1.1.1 (the DAC setup issue was fixed in v1.1.0).

Either that or delete lib_board_support entirely and change the entry in app_an02003/CMakeLists.txt to:

set(APP_DEPENDENT_MODULES "lib_i2c(6.2.0)"
"lib_i2s(5.1.0)"
"lib_adat(2.0.0)"
"lib_spdif(6.1.1)"
"lib_sw_pll(2.2.0)"
"lib_logging(3.2.0)"
"lib_src(2.6.0)"
"lib_xassert(4.2.0)"
"lib_xcore_math(2.2.0)"
"lib_board_support(1.1.1)"
)

The next time you build it will grab/clone the latest version.

The core ASRC is very well tested so I would be very surprised if this was the cause of your issue.

Please try this - apologies for the bad experience but appreciate you taking the time to report it. Let us know if it fixes it (especially if not as we will need to do some more digging).

I have raised this internally and we will get AN02003 updated with the latest dependent modules ASAP so others don't have to suffer!

Ed

[paulvongrundan]

Hi Ed, Hi Joe,
both of you were right. lib_board_support v1.1.1 solved the aliasing issue on the DAC output and reducing the digital input signal level to about -0.1 dBFS solves the issue with the I2S signals clipping above 1 kHz with static signals.
Thank you very, very much for taking the time to look at my problems.

Since the digital filters of the sample rate conversion of the AN02003 can introduce quite a lot of overshoot in the digital stream, the input level needs to be backed down by at least - 3 dBFS when a step function is played back to avoid clipping. Although this becomes obvious once you thought about it XMOS could maybe add a small disclaimer in the documentation, so, that beginners like me are aware.

With the new build of the project and enough digital headroom we get the following performance (96 khz in/out:

5 kHz -01dB.jpg

The sweep (at -3 dBFS) also looks clean now:

THD.png

The analogue output of the DAC behaves:

IMG_2136.jpg

Thank you very much, again, for your help.

When looking at the oscilloscope I had only one question left. There is still something funny going on with the waveform which cannot really be shown in a picture. I would describe it like small, jittery artifacts moving through the waveform. The behaviour can be changed by the output sample rate.
Clearly, it is not a real jitter, since the APx would pick that up and also show a poor SINAD which it clearly does not. Do you know what I mean?

Best regards,
Paul

[michaelf]

...and reducing the digital input signal level to about -0.1 dBFS solves the issue with the I2S signals clipping above 1 kHz with static signals.
Thank you very, very much for taking the time to look at my problems.

Since the digital filters of the sample rate conversion of the AN02003 can introduce quite a lot of overshoot in the digital stream, the input level needs to be backed down by at least - 3 dBFS when a step function is played back to avoid clipping. Although this becomes obvious once you thought about it XMOS could maybe add a small disclaimer in the documentation, so, that beginners like me are aware.

I wonder these points here could be elaborated upon, regarding the requirement to run at less than 0dBFS? Is this a function of the implementation of the ASRC i.e. using fixed point maths, or is this common to any ASRC implementation?

[Joe]

Glad this fixed it!

We have a bit of fine tuning to do on the levels from the looks of it as as you noted it might clip with large square wave signals. This is due to the Gibbs phenomenon causing overshoot/ringing once passed through the sharp filters in the ASRC.

In terms of the "jittery" things you're seeing on the waveform was this on the analogue output from the mc audio board or in the i2s data? The mc audio board dacs do have quite a bit of out of band noise around the sampling rate of 384kHz (after the oversampling filter) as they just sample/hold from here up to the delta sigma dac rate. Maybe you could be seeing that:

https://e2e.ti.com/support/audio-group/ ... nity-check

[infiniteimprobability]

Hi All,
very glad you are seeing good results now - The SINAD of the ASRC is very high (130dB+) which equates to 22 bits+ so should comfortably exceed the performance of even very high quality DACs.

Regarding the Gibbs Phenomenon you are seeing, it is a characteristic of any filter where a square wave has some of its higher harmonics filtered, like in any low pass filter. SRCs are fundametally just FIR low pass filters at heart and so behave this way. As you have measured, it doesn't affect the performance or audible characteristics of the signal.

BUT it does have an important usage note that a 0dB FS square wave (or anything with with steep transitions in the time domain) can cause the filters to clip in our implementation which is because we maximise the dynamic range for the integer calculations.

One workaround, if you need to account for sharp input waveforms at 0dB FS, (which isn't unreasonable for an audio application) is to pre-attenuate by 10% and post-amplify by 10% around the SRC. One way to do that with very high precision (and accounting for rounding errors) using a 64b intermediate, which is quite efficient in the XCORE, is:

Code: Select all

const int precision = 30;

int32_t atten_10pc(int32_t val){
    int32_t mul = 0.9 * (1 << precision);
    int64_t tmp = (int64_t)mul * (int64_t)val + (1 << (precision - 1));
    return (int32_t)(tmp >> precision); 
}

int32_t amplify_10pc(int32_t val){
    int32_t mul = (1 << precision) / 0.9;
    int64_t tmp = (int64_t)mul * (int64_t)val + (1 << (precision - 1));
    return (int32_t)(tmp >> precision); 
}

We'd value your input - does it make sense to add a note about this in just lib_src or AN02003 also? Or even add these pre/post steps in the app note with comments? My sense is add to both docs and the app note codebase.

[paulvongrundan]

Hi everyone,
in my opinion the AN2003 could stay the way it is implemented right now, since the level of attenuation in a real life additionally needs to account for the DAC implementation (and the DAC's filter(s)). A short note in the documentation of the AN02003 for the people to watch out for the Gibbs Phenomenon while measuring the performance would be really nice. In my opinion adding the note to the library might be a little overkill as this knowledge could be assumed.

@infiniteimprobability Thank you very much for the workaround.

@Joe

In terms of the "jittery" things you're seeing on the waveform was this on the analogue output from the mc audio board or in the i2s data? The mc audio board dacs do have quite a bit of out of band noise around the sampling rate of 384kHz (after the oversampling filter) as they just sample/hold from here up to the delta sigma dac rate. Maybe you could be seeing that:
https://e2e.ti.com/support/audio-group/ ... nity-check

Thank you for pointing that out. That was my bad. I did not check that the jittery analogue signal is always present on the PCM5122 DAC, and on all available sample rates.

If that is OK with you, allow me one last (maybe a little uninformed) question: While I agree, that the measured performance of the ASRC is absolutely wonderful I do not agree with the statement that the impact of the ASRC is not audible. Is there an easy way to switch to slow roll off filters with less ringing without rewriting the whole AN2003?

Best regards,
Paul