Configuring RT1020-EVK for 24-bit audio sampling

[dykwong]

For audio sampling, the MIMXRT1020-EVK is built with the WM8960 codec. According to the datasheet, it is capable of capturing stereo 24-bit samples at 48kHz.

Apparently all example projects in the SDK only features configuration for capturing 16-bit samples. So we have experimented with modifying various settings using the SDK example project dev_composite_hid_audio_unified_lite as the starting point.

For the WM8960, we have made use of the predefined constant kWM8960_AudioBitWidth24bit. See below:

wm8960_config_t wm8960Config = {
.i2cConfig = {.codecI2CInstance = BOARD_CODEC_I2C_INSTANCE,     .codecI2CSourceClock = BOARD_CODEC_I2C_CLOCK_FREQ},
.route = kWM8960_RoutePlaybackandRecord,
.leftInputSource = kWM8960_InputDifferentialMicInput3,
.rightInputSource = kWM8960_InputDifferentialMicInput2,
.playSource = kWM8960_PlaySourceDAC,
.slaveAddress = WM8960_I2C_ADDR,
.bus = kWM8960_BusI2S,
.format = {.mclk_HZ = 12288000U,
.sampleRate = kWM8960_AudioSampleRate48KHz,
.bitWidth = kWM8960_AudioBitWidth24bit},
.master_slave = false,
};

And we have also increased the audio PLL frequency to 883.20MHz from the original 786.48MHz.

While the above settings produced 24-bit audio samples at 48kHz, the quality of the captured signal was poor in terms of THD. So we would guess that the sampling clock settings require further tuning.

It would be immensely helpful if anyone could point us to any official documentation on the audio clock setting, and better still, examples to illustrate the correct configuration.

Many thanks!

[PabloAvalos]

Hi @dykwong 

Thanks a lot for reaching our technical support.

First of all, I would like to be situated at some starting point. I would like to know if with the 16-bits resolution (original example from SDK without modifications), is the example recording well and keeping the good quality of the captured signal ? did you already tried this example first and connections are well done?

I highly suggest you to follow the readme.pdf file that comes with the example on the path: "C:\Users\...\Documents\MCUXpressoIDE_11.7.0_9198\workspace\evkmimxrt1020_dev_composite_hid_audio_unified_lite_bm\evkmimxrt1020\usb_examples\usb_device_composite_hid_audio_unified_lite\bm" to have the example running well at 16-bit resolution @ 48kHz sample rate. Then we can look forward to increase the resolution up to 24-bit.

Additionally, if you want to explore an alternative option, you may read the next post in our community to have as alternative to test. 

https://community.nxp.com/t5/i-MX-RT/I2S-dma-driver-2x24-bits-transfer-problem/m-p/1170424#M10739

I will stay tuned to your comments. Thank you!

BR.
Pablo Avalos.

[dykwong]

Thank you for responding, Mr. Avalos.

Our primary target is to set up the RT1020-EVK as a USB microphone. But for the ease of studying the other capabilities on the USB bus, we have chosen to experiment with a USB composite device.

We have indeed built the unmodified version of the dev_composite_hid_audio_unified_lite project. By feeding an 1kHz sinewave into the 3.5mm socket on the RT1020-EVK, we have successfully captured 16-bit samples of the sinewave at 48kHz on the left channel. (The right channel on the WM8960 codec takes its input from the onboard microphone on the EVK.) So far so good then.

So as to realise our design goal of capturing and delivering the 24-bit samples at 48kHz, we have identified the following actions to be taken:

1. Configure the WM8960 codec to produce 24-bit samples at 48kHz.
2. Resize the sample buffers to accommodate 3 bytes per sample.
3. Adjust the clocks to ensure that 48kHz 24-bit samples are delivered at exactly the right rate via the Audio SAI.
4. Configure the USB device descriptor to deliver 24-bit samples to the USB host PC.

For (1), the modification in "wm8960Config" appears straightforward.

For (2) and (4), we have a working solution where each audio sample is delivered in 4-byte words (where each 24-bit sample occupies the most significant 3 bytes, and the bottom byte padded with 0). We have filled the sample buffer with a static sinewave pattern in 24-bit precision to simulate an ideal 24-bit codec, and this sinewave was perfectly captured on the host PC.

However, for step (3), we do not appear to have sufficient understanding of how the audio clock and SAI are related. By increasing the Audio PLL frequency to 883.20MHz from the original 786.48MHz, we can see that 24-bit samples from the WM8960 codec can be transferred over SAI to the RT1021.

When we examine these 24-bit samples which were delivered to the host PC, the purity of the 1kHz sinewave fell short of expectation in terms of THD.

Let me apologize for the long write-up.

[PabloAvalos]

Hi @dykwong 

It is ok the long write, do not worry. Indeed it is a good explanation, and it is something that I would like to test. By any chance, do you think you may share your code/project with us so we can reproduce the issue and realize why this poor quality is getting recovered by the samples?

You may share it here, or if it is confidential, you may share it by e-mail in a Support Ticket directly with us (not in the community), so we can reproduce the same on our RT1020-EVK and check what is going on.

I will stay tuned to your comments.

BR.
Pablo Avalos.

[dykwong]

Thank you for the quick response, Mr. Avalos.

In our investigation, only 4 files in the dev_composite_audio_unified_lite_bm project from the SDK were modified.

Please see the attachments.

1. Modifications in the USB device descriptor should be fairly obvious to experienced developers.
2. Since we are developing and testing on Windows 10, we have set USB_DEVICE_WORKAROUND_AUDIO_20_WINDOWS to 1 to enable the USB audio 2.0 workaround.
3. The only potentially tricky step is to align each 24-bit sample from the WM8960 codec (via SAI) to occupy the top 3 bytes of each 4-byte word in the USB audio recorder buffer.

BTW, we are using MCUXpresso v11.7.0.

Our basic evaluation environment is really simple - Just a sinewave signal generator feeding 1kHz through the 4-pole socket on the RT1020-EVK. On the Windows 10 USB host, the digitised sinewave on the left channel is captured and the THD measured.

Once again, we would like to have more information on configuration the audio PLL to establish if it is the cause of the degradation. As it is, we cannot demonstrate any measurable benefit in going to 24-bit sampling and make best use of the capabilities of the RT1021.

Your help is much appreciated.

[PabloAvalos]

Dear @dykwong 

Thanks a lot for the codes provided and the additional information.

Now I have a lot of cases in my testing queue, so I would appreciate some more time to do the corresponding test for you to tell you my comments about your issue. I need to check the proper PLL frequency so you cannot experiment that degradation.

Thanks a lot for your patience, I will make sure to reach you back as soon as possible.

Best Regards.
Pablo Avalos.

[dykwong]

Thank you for responding, Mr. Avalos.

Perhaps we can work in parallel if you could point us to the relevant documentation.

Your help is much appreciated!

[PabloAvalos]

Hi @dykwong 

Please accept my apologies for the long delay on my response. I was having a lot of requests on my testing queue before.

I just tried to reproduce your issue, but not succeed properly. First of all, clarifying there's not a document to help on this issue so far, If I have or find something useful, I will make sure to share it with you.

In the meantime, I was working on your issue and testing the example from the SDK and your modified codes. I did not realize of something weird, but some questions I have for you just to follow-up, may I know where did you input the sinusoidal 1kHz signal ? if it was through the jack (J11 on EVK), what was the signal that you measured with RT or your computer after passing through CODEC from RT? Degradation? Attenuation? Something?

Then, I would like to know if you have some screenshots or photos of an oscilloscope or some other tool where you capture your original sinusoidal 1kHz signal and the received 1kHz sinusoidal after the samples/transmission/etc. Because, we need to know that channel (wired in this case) is not affecting the integrity of the signal that you are sampling with the RT.

I will stay tuned to your reply or new comments/updates you may have. Thanks a lot for your patience!

BR.
Pablo Avalos.

[dykwong]

Thank you, Mr. Avalos.

Your hard work is most appreciated.

As we have stated previously, the objective is to set up the RT1020-EVK to prototype a USB microphone by means of the example project usb_device_composite_hid_audio_unified_lite.

The analogue audio input indeed makes use of the J11 socket, which is connected to the WM8960 codec. We have paid attention to the specific pinouts of the 4-segment 3.5mm socket.

The digital audio samples captured are sent to the USB host PC. Just like many developers, we use Audacity to capture these audio samples. The input port is the Microphone (USB AUDIO+HID DEMO).

We feed the analogue audio input (1kHz sinewave) from a signal generator. Then we studied the captured waveform. As you can see in the attachment, the 1kHz sinewave is reasonably clean.

However, when we zoom in to view to within 5ms, one can see that the waveform is only mostly sinusoidal. The sampling clock seemed to have suffered some offset, drift or jitter. This is why we started experimenting with the PLL clock settings.

We have increased it from the default 786.48MHz to 883.20MHz, and got a somewhat improved sinusoid.

But when we increased it much further to 1083.648MHz, we can see severe discontinuities.

This is why we were looking for documentation on the PLL setting.

Once again, this is getting quite long and detailed.

Please let us know if you have difficulties reproducing our observations.

[PabloAvalos]

Hi @dykwong 

Thanks a lot for your detailed explanation on how you are setting up everything, in order to help you.

I was trying to reproduce your observations to be on the same page than you, but with no success.

I am wondering how did you capture the 1kHz signal through the Jack 3.5mm connector from the RT-EVK and then show it on Audacity, I am just running the example with your files included and the only audio I can record is from the external mic that has the EVK. I am using Matlab to capture the 1kHz sinusoidal signal sent with a functions generator first and it is captured well, but if a connect the aux from the generator to the RT, I cannot see any audio recorded through the USB, how did you do that test so I can figure it out.

Then, I would like to know which is the amplitude of the sinusoidal signal sent? and what is the amplitude of the signal received? And what is the sample frequency you are using with the CODEC from RT? and the sample frequency and other setting you put on Audacity? just to make sure that setup is ok.

Also, I tried to point for some PLL setting documentation for SAI interface on RT, but I did not find nothing internally, if the issues persists for a little bit more time, I think I can reach one apps engineer to get more support on this, but firstly I want to hit the nail on the head by myself as soon as possible.

Hope we can find the solution together as soon as possible, I will stay tuned for your new comments, just to be at the same page.

Thanks a lot!

BR.
Pablo Avalos.

[dykwong]

Thanks, Mr. Avalos, for giving it a try.

Let me illustrate our hardware configuration in more detail in the following diagram.

There are some points worth noting:

1. The 4-pole socket J11 has both input and output pins. We use the only input pin to feed in the 1kHz signal. If connected correctly, the sinewave can be displayed on an oscilloscope by probing TVS5. Here is an excerpt from the RT1020 schematic drawing (SPF-29856_B1).

2. As specified in wm8960Config.sampleRate, the codec sample rate is 48kHz (kWM8960_AudioSampleRate48KHz).

3. The magnitude of the analogue 1kHz sinewave is about 160mV peak-to-peak. This corresponds to about 80% of full-scale on Audacity.

4. Audacity is configured with a project sample rate of 48kHz.

I hope this clarifies any uncertainty.

[PabloAvalos · Accepted solution]

Dear @dykwong 

Thanks a lot for the patience on this case.

Since this is non-standard configuration (not "officially" supported) and with the tools that we have to provide our support was not able to bring you a solution, my recommendation is not to look at the PLL frequency for SAI module, as you are using a PLL original frequency of 786.48MHz, that is more than enough for the sample rate of 48kHz you are managing with the Codec and SAI interface.

Then, TVS5 as far I see is the pad from the board where the TVS diode is connected and also connected to an inductor, so if you are using some wire welded there, the signal integrity through this wire might be seen affected and probably sinusoidal signal is not as perfect as you expect.

Lastly, I can suggest you to still looking at our community posts from other i.MXRT, or i.MX inclusively, to look for more information about the issue. Here, I will add a couple of links that might be helpful, but then you can find a lot of information on our community threads.

Link 1

Link 2

Hope you may find the solution for the issue, please feel free to open a new ticket for our support team, in case you still need more help or you have more specific questions, because this ticket is getting old right now, so you can receive a follow-up on the case and it may be researched beyond.

Thanks a lot for the comprehension.

BR.
Pablo Avalosl