I.MX RT1010EVK USB Audio 24 bit ?

[carotte]

Dear NXP community,

I am currently experimenting with the I.MX RT1010EVK and the SDK example „evkmimxrt1010_dev_audio_speaker_freertos“.

In its original state, it works fine and is recognized by Windows as supporting only 48 kHz/16 bits.

I now wanted to add 24Bit support and made the according changes to the USB descriptors and defines of the example code.

I didn’t make any changes to the codec code because at this stage, I am only interested in making the device appear correctly in Windows.

With these code changes, the device is still recognized by Windows, but something is not right. 

The “advanced” tab in speaker properties is missing, and playing a test sound is not possible.

It would be great if anyone could help me resolve this issue or point me in the right direction.

Thanks!

[MHY_0878]

Hello, have you solved this problem, I am a newbie, I would like to ask about this problem.

[carotte]

Hi @EdwinHz ,

Thanks for getting back to me.
Yes, I have read the full documentation.

"Try enabling the "USB_DEVICE_WORKAROUND_AUDIO_20_WINDOWS" macro as mentioned on this file"

Im am using windows 11, the unmodified example worked flawlessly even without this macro enabled.
Still, when encountering the described issue I tried setting this macro, but the described outcome is unaffected by it.

"or try changing the "USB_DEVICE_CONFIG_AUDIO_CLASS_2_0" macro to 0 in the usb_device_config.h header"

Could do, but I see little point in doing so, as I am after creating a UAC2 device, not UAC1.

It would be great if you could give more suggestions.
Thanks in advance!

[EdwinHz]

Hi @carotte,

Your modifications are OK, and follow accordingly the fields to modify that are described by my colleague on this post: USB Audio Class: Explanation of the feedback sync function - NXP Community

USB_DEVICE_WORKAROUND_AUDIO_20_WINDOWS can remain disabled and USB_DEVICE_CONFIG_AUDIO_CLASS_2_0 should also remain in 1.

Are you certain the USB module is running at the default 480MHz?

The following article goes into a lot of detail on how to create a proper USB Audio Class application with config tools: USB Audio Class Tutorial - NXP Community

In that case, changing the bit format would be as simple as changing the resolution field shown on Figure 7.

BR,
Edwin.

[carotte]

Hi @EdwinHz,

I already discovered both linked articles.

As for the ladder (using the config tool), it yields the exact same result as my manual modifications to the freeRTOS based example code. 
With 16bits it will work correctly (be recognized as a speaker with all the Windows tabs); with 24bits it will be recognized, but not as a functioning device (tabs missing, error on playback).

As it is - by your own admissions - as simple as changing a single number, you could verify this behavior yourself to see it aligns with what I describe.

As for the comments by your colleague on the other thread, I don't think they are relevant in this case.
Seemingly, the person asking already has a setup that enumerates properly with Windows, which isn't the case here. 

I don't usually post questions here without significant amounts of research and trying around in advance.
I think it would be beneficial if you could try out these simple changes yourself, and if you can replicate my results, investigate further.
I'd be very thankful to hear about your findings!

Thanks!

[carotte]

PS.:

From all the posts I've read of people attempting to change the bit depth, the device enumeration seems to not have been the problem - rather buffer under/overflows.

However, all these posts were from a much earlier SDK version (pre 2.9). This might be something to investigate. 

[EdwinHz]

Hi @carotte,

I have replicated the issue and corroborated that the "Advanced" tab does not appear when the device is set up with 24-bit depth.

That said, a dump from the USB enumeration process did show that the enumeration is set up with 24-bit resolution.

I also checked on a Linux machine using "alsa-info" and it once again enumerates as 24-bit:

!!USB Stream information
!!----------------------
--startcollapse--

NXP SEMICONDUCTORS USB AUDIO DEMO at usb-0000:00:14.0-3, high speed : USB Audio

Playback:
Status: Stop
Interface 1
Altset 1
Format: S24_3LE
Channels: 2
Endpoint: 0x02 (2 OUT) (ASYNC)
Rates: 48000
Data packet interval: 125 us
Bits: 24
Channel map: FL FR
Sync Endpoint: 0x82 (2 IN)
Sync EP Interface: 1
Sync EP Altset: 1
Implicit Feedback Mode: No
--endcollapse--

This led me to think that the missing tab and play testing was caused by the windows side of things. Perhaps Windows' advanced settings only supported specific audio formats and having a "non-conventional" 24-bit 48000 Hz format caused this issue? I proceeded to change the "AUDIO_SAMPLING_RATE_KHZ" to 96 and indeed, the Advanced tab was back:

The frequency is off, but the fix to this issue is described and fixed on the following community post: Solved: RT1020 UAC2 example Sample Rate issue - NXP Community

I hope this helps!

BR,
Edwin.

[carotte]

Hi @EdwinHz,

Thanks for investigating!

Yes, I also tried dumping the USB descriptors and found no obvious problem with the 24-bit setup.
I didn't try it on Linux, but my Mac also recognized it as a 24-bit device. But did you manage to get any sound from it (on Linux) which was not just noise?

My suspicion is, that Windows performs some kind of sanity/integrity check that MacOS and Linux don't.
Perhaps it sends over some empty audio samples when the device is first detected and verifies the feedback received. If it doesn't align with what Windows expects, it enters a state where the device is seen as non-functional and the tabs are missing.
Even with the missing tabs, you can right-click the device and select "test".
With the 24-bit setup, Windows will not even try to play any sound but throw an error right away, so it knows that something about the device is off.


For the 96 kHz test, did you use another board?
If I try it on my RT1010 EVK, it tells me that I have insufficient RAM:

c:...../../../../arm-none-eabi/bin/ld.exe: dev_audio_speaker_freertos.elf section `.stack' will not fit in region `m_data'
c:.../../../../../arm-none-eabi/bin/ld.exe: region m_data overflowed with stack and heap
c:..../../../../arm-none-eabi/bin/ld.exe: region `m_data' overflowed by 632 bytes
Memory region Used Size Region Size %age Used
m_flash_config: 512 B 3 KB 16.67%
m_ivt: 48 B 4 KB 1.17%
m_interrupts: 1 KB 1 KB 100.00%
m_text: 83040 B 16375 KB 0.50%
m_qacode: 0 GB 32 KB 0.00%
m_data: 33400 B 32 KB 101.93%
m_data2: 10156 B 64 KB 15.50%

Changing this macro alone (without the parts described in the liked post, which are for advertising the samplerate to the host) would only affect the audio data buffers and the feedback. 
This would reinforce my suspicion that this is feedback-related. 

[EdwinHz]

Hi @carotte,

I'm afraid I didn't get the chance to test much further than what I described on my last reply. That said, I did use a MIMXRT1010-EVK board to do the "#define AUDIO_SAMPLING_RATE_KHZ (96)" change and didn't experience any RAM overflow issues. Nonetheless, the FlexRAM features of the i.MX RT series allows for adjusting the RAM sections depending on the developer's needs. This adjustment process is described on the following application note: AN12077: Using the i.MX RT FlexRAM – Application Note (nxp.com).

You can try adjusting the overflowed region to compensate for the overflowing stack and test the sampling rate change to 96KHz. This should allow windows to properly detect the device and show the "advanced" tab again.

BR,
Edwin.

[carotte]

Hi @EdwinHz ,

It's strange that the same code would result in different amounts of RAM usage on both our sides. 
Would you mind sharing your project to make sure we're on the same page?

Thanks!

[EdwinHz · Accepted solution]

Hi @carotte,

Of course. This is the code I used for testing.

I hope it helps!

BR,
Edwin.

[carotte]

Hi @EdwinHz,

after testing your code, I actually found out that (at least part of) my issue was unrelated to issues with the MCU firmware.
It seems that windows sometimes doesn't "recover" from a faulty device configuration, so the tabs would remain missing, even if the configuration was fixed.

I had to uninstall the device from the device manager and reconnect it to test the new configuration. This caused a lot of confusion.

Thanks a lot for your support!

[EdwinHz]

Hi @carotte,

Have you read the readme.pdf file that comes attached on the SDK for this example code? It can be found on the following path:

<MCUXpresso_SDK_Install>/boards/<board>/usb_examples/usb_device_audio_speaker_lite/<rtos>/readme.pdf.

The section on the bottom describes several notes to have in mind when implementing this example code. One of the notes talks about incompatibility with Windows 10. Try enabling the "USB_DEVICE_WORKAROUND_AUDIO_20_WINDOWS" macro as mentioned on this file, or try changing the "USB_DEVICE_CONFIG_AUDIO_CLASS_2_0" macro to 0 in the usb_device_config.h header.

BR,
Edwin.