USB Microphone corrupted data/missing data

[PVS_Bram]

Hi everyone

I have developed a custom board using the XU316-1024-QF60B. The design is based/tested on the USB MULTICHANNEL AUDIO EVALUATION KIT which uses a XU316-1024-TQ128 and the firmware is based on the sw_usb_audio example. I used the eval kit to develop the firmware and determine which parts I would like to use.

The kit is configured to work as an Asynchronous USB stereo input/output, 48000 Hz, 32 bit with the I2S Codec as the master for the I2S line. This works great on the evaluation kit. Using the custom created board is where the troubles begin. The board configuration (.xn) files are changed (ONLY CHANGES MADE: Packages >> Package >> Type; DAC (XS1_PORT_1F --> XS1_PORT_1P)/ADC (XS1_PORT_1G --> XS1_PORT_1I) pins). Running the firmware works as expected and shows the prints in the terminal. When connecting the USB to the host machine (Windows) it is recognized as expected (USB Microphone and USB Speaker). Testing the USB speaker showed that the data that is being send over I2S as a slave works great. However, the USB microphone does not have the same result. Meaning that I2S data is being sent from the other CPU (ESP) in the same I2S configuration, but is not parsed correctly by the XMOS resulting in corrupted USB MIC data. A simple sine wave is sent over I2S.

When monitoring the incoming I2S datalines using a logic analyzer, everything looks correct and as expected as shown below:

MonitorI2S_External.png

When monitoring the USB Mic Packets using the device monitoring studio, it shows that the packets of data have missing data, as shown below:

USBPackets.png

When the USB mic is recorded in Audacity. The resulting recording is shown below. (played audio top, recorded audio below)

Audacity_Recording_USB_MIC.png

Thanks for you advice.

Bram

[PVS_Bram]

Also, the schematic-, board files for the custom design are attached below.

[Ross]

It looks like I2S_MCLK should also go to X0D00 but "usb_refclK" signal is presented there (not sure what that is of course)

[Joe]

So you have setup the xmos device to be I2S slave (LRCK, BCLK are inputs) and your other device is an I2S master with LRCK, BCLK as outputs?

What is your master clock config? I assume you have the xmos as master clock master (MCLK is output) and you are passing this to the other device (MCLK is input)?

[PVS_Bram]

It looks like I2S_MCLK should also go to X0D00 but "usb_refclK" signal is presented there (not sure what that is of course)

The usb_refclk is the I2S_MCLK signal. I thought that the XMOS used this Master clock as a reference to determine the feedback value for asynchronous USB transfer mode.

[PVS_Bram]

So you have setup the xmos device to be I2S slave (LRCK, BCLK are inputs) and your other device is an I2S master with LRCK, BCLK as outputs?

What is your master clock config? I assume you have the xmos as master clock master (MCLK is output) and you are passing this to the other device (MCLK is input)?

The other master clock is received from the ESP (master clock master). This is because the I2S also needs to be synced to a Dante network. Can this have any performance impact on the USB mic?

[Joe]

My thinking is If all of the I2S signals and MCLK are inputs then most likely there is something wrong with one of them otherwise the system should work correctly (as on the dev board). The mic input you recorded shows blocks of samples being dropped rather than data corruption which points to a mismatched data/clock rate somewhere in the system.

I assume the build was done for a fixed 48kHz sample rate only in terms of supported sample rates? That makes things a lot easier. The master clock input must be a free running clock at the correct freq as specified in the build, I assume 24.576MHz. Assume all the USB host/driver/config settings are set to 48kHz?

Struggling to think what else could be wrong.

[PVS_Bram]

My thinking is If all of the I2S signals and MCLK are inputs then most likely there is something wrong with one of them otherwise the system should work correctly (as on the dev board). The mic input you recorded shows blocks of samples being dropped rather than data corruption which points to a mismatched data/clock rate somewhere in the system.

I assume the build was done for a fixed 48kHz sample rate only in terms of supported sample rates? That makes things a lot easier. The master clock input must be a free running clock at the correct freq as specified in the build, I assume 24.576MHz. Assume all the USB host/driver/config settings are set to 48kHz?

Struggling to think what else could be wrong.

The build was indeed made for a fixed 48 kHz sample rate. The master clock has a frequency of 12.28 MHz. I am not sure what you mean with "USB host/driver/config settings"? I have specified my configuration in the Makefile using the configuration parameters specified in 'XUA_CONF_DEFAULT'. In which both max and min frequency are set to 48000 Hz.

[Ross]

Do you have MCLK_48 defined to the correct value (256 * 48000)? The default in the app you started from is likely (512 * 48000). If its doesn't match then the feedback calculation will be wrong and you'll probably get something you have (under/over-flows)

[Joe]

Unless you have changed the definition in xua_conf.h then the default MCLK frequency for 48kHz should be 24.576MHz.

#define MCLK_48 (512*48000) /* 48, 96 etc */

So a 12.288MHz MCLK would cause major issues.

You can just change the define to

#define MCLK_48 (256*48000) /* 48, 96 etc */

and give it a go.