USB Microphone corrupted data/missing data

Discussions about USB Audio on XMOS devices
PVS_Bram
Member++
Posts: 18
Joined: Fri Jan 12, 2024 11:20 am

Post by PVS_Bram »

Changing the MCLK as you suggested improved the quality of audio data significantly. I still seem to have some drops in the audio.

As you can see in Audacity:
Spectogram_MicUSB.png
Audacity_Recording_USB_MIC.png

And as well in the Device Monitoring Studio:
AudioData_MicUSB.png
You do not have the required permissions to view the files attached to this post.
PVS_Bram
Member++
Posts: 18
Joined: Fri Jan 12, 2024 11:20 am

Post by PVS_Bram »

Also the FB value seems to give some strange values:
AudioFB_MicUSB.png
You do not have the required permissions to view the files attached to this post.
User avatar
Ross
Verified
XCore Expert
Posts: 985
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

I would separate your usb streaming and hardware interface debug by doing a loopback in the xcore software.

for example, implement:

Code: Select all

void UserBufferManagement(unsigned sampsFromUsbToAudio[], unsigned sampsFromAudioToUsb[])
{
    // Loopback usb -> usb for channels 0 and 1
    sampsFromAudioToUsb[0] = sampsFromUsbToAudio[0];
    sampsFromAudioToUsb[1] = sampsFromUsbToAudio[1];
}
if this works then debug the hardware interface, if this fails then there's still something up with your usb streaming.
User avatar
Ross
Verified
XCore Expert
Posts: 985
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

PVS_Bram wrote: Fri May 24, 2024 12:25 pm Also the FB value seems to give some strange values:
AudioFB_MicUSB.png
looks to be sitting around 6 or just under if im reading your output correctly, (16:16 fixed point value of number of samples per micro frame).

So it looks correct assuming you're streaming at 48k. The microframe rate is 125uS, leading to 48000/8000 = 6.
Joe
Verified
Active Member
Posts: 51
Joined: Sun Dec 13, 2009 1:12 am

Post by Joe »

Getting there!

MCLK needs to be synchronous with the BCLK and LRCK from the ESP (i.e. all sourced from the same clock source). If not the data rates will drift over time and cause buffer under/overflows.

I would expect drops in the i2s output as well as input though in this case but you say the output data has no drops?
XMOS hardware grey beard.