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:
And as well in the Device Monitoring Studio:
USB Microphone corrupted data/missing data
-
- Member++
- Posts: 18
- Joined: Fri Jan 12, 2024 11:20 am
You do not have the required permissions to view the files attached to this post.
-
- Member++
- Posts: 18
- Joined: Fri Jan 12, 2024 11:20 am
Also the FB value seems to give some strange values:
You do not have the required permissions to view the files attached to this post.
-
Verified
- XCore Legend
- Posts: 1070
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
I would separate your usb streaming and hardware interface debug by doing a loopback in the xcore software.
for example, implement:
if this works then debug the hardware interface, if this fails then there's still something up with your usb streaming.
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];
}
Technical Director @ XMOS. Opinions expressed are my own
-
Verified
- XCore Legend
- Posts: 1070
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
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.
Technical Director @ XMOS. Opinions expressed are my own
-
Verified
- Experienced Member
- Posts: 66
- Joined: Sun Dec 13, 2009 1:12 am
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?
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.