Does the nrf5340 audio DK can support the mutichannel USB device?

[huma]

Hello,

In the nrf5340_aduio application. I found it support 2 channels both of output(mic signal) and input(audio signal) on the USB device.

But i want to know if it can support mutichannel for the USB devic? for example, support 4 or 6 channel mic signal to PC through USB.

I know if that possible, the driver and the audio process part both need to modify.

But first step i want to modiify the driver part first to make the PC can identify the decice has up to 4 or 6 channels, Even if it is only displayed on a PC, the audio part cannot function properly.

In the default sample, the Windows11 can recognized it:

Then I have tried to add the "mic-channel-c;" to the dt overlay file.

&hs_0 {

    mic-channel-c;

};

Then the PC seems can recognized the USB audio device, but there is no Advanced page to check the channel:

So can you help me to modify the driver part to make the PC can identify the right number of the channles?

I think if the driver part work well, then i can go to modify the audio processing part.

Thank you very much!

[Håkon Alseth]

Hi,

 

Please note that the audio class implemented is UAC1, as explained here:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/connectivity/usb/device/usb_device.html#audio

A limiting factor here will be the USBD peripheral, which is 2.0 compliant, but runs on USB full-speed (12Mbit PHY). Note that you are enabling more channels than we have tested for, so please be aware that this can potentially be problematic.

 

For the nRF5340-audioDK, this is the default setup (ie. mic L/R + stereo output):

https://github.com/nrfconnect/sdk-zephyr/blob/v3.5.99-ncs1-1/boards/arm/nrf5340_audio_dk_nrf5340/nrf5340_audio_dk_nrf5340_cpuapp_common.dtsi#L289-L303

 

You can change this by changing the boards/$BOARD.overlay:

&usbd {
	hs_0: hs_0 {
		compatible = "usb-audio-hs";
		mic-feature-mute;
		mic-channel-l;
		mic-channel-r;

		hp-feature-mute;
		hp-channel-l;
		hp-channel-r;
	};
};

 

Please note that when you're using windows, your USB descriptor will be cached. If you adjust parts of your usb descriptor after initial enumeration, windows will still load the first one.

To avoid this, the easiest is to change the USB VID/PID (PID=PID+1 for instance) to force a new enumeration.

 

Kind regards,

Håkon

[huma]

Hello Håkon,

Thank you very much for your reply. 

Please note that when you're using windows, your USB descriptor will be cached. If you adjust parts of your usb descriptor after initial enumeration, windows will still load the first one.

To avoid this, the easiest is to change the USB VID/PID (PID=PID+1 for instance) to force a new enumeration.

That is the reason why my PC can not  recognize, when i had changed the pid and vid, it worked.

I will do some test, then work for the audio part, maybe there will be more questions to consult with you later.

Thank you very much!

[huma]

Hello Håkon,

Thank you for your reply.

Does the USB device support the 16K sampling rate? The default is 48K but I did not find where can i modify, i think it is also the driver part.

Thank you very much and looking forward for your reply.

[Håkon Alseth]

Hi,

 

By default, the sampling rate is hard-coded to 0x00bb80 (48000 Hz) in this file:

https://github.com/nrfconnect/sdk-zephyr/blob/v3.5.99-ncs1-1/subsys/usb/device/class/audio/usb_audio_internal.h#L494

 

In upstream zephyr and ncs main, this commit has been added:

https://github.com/nrfconnect/sdk-zephyr/commit/975208209b589517d84eb08f9565a0f286907277

 

Which allows you to change the sampling frequency in device tree for future versions. But for the current ncs v2.6.x and older, it is unfortunately hard-coded in the above linked .h file.

 

Kind regards,

Håkon

[huma]

Hello Håkon,

Thank you for your reply.

I'm glad there's a way to modify the sampling rate.

I will try to verify this feature in the next few days, and if there are any issues, I will continue to come back to you for advice.

Thank you very much!

[Håkon Alseth]

Hi,

 

huma said:

Hello Håkon,

Thank you for your reply.

I'm glad there's a way to modify the sampling rate.

I will try to verify this feature in the next few days, and if there are any issues, I will continue to come back to you for advice.

Thank you very much!

I'm always happy to help out. Let me know if you run into any issues or problems, and I'll try to help out!

 

Kind regards,

Håkon

[huma]

Hello Håkon,

I am back to ask for help.

With your help, I successfully implemented multi-channel USB device functionality and changed the sampling rate to 16K.

But when I was debugging, I found that my I2S clock would have an extra cycle every 55 seconds, which would result in my USB not having enough data to fill the I2S buffer. By the way, the audio data in my project is blocking every two milliseconds.

I have seen in the nrf5340-audio example that drift compensation is called to each I2S interrupt. Is this intended to improve the issue of inaccurate I2S clocks?

So, is there any other way for my I2S to synchronize with the USB clock while working?

Thank you very much and looking forward for your reply.

[Håkon Alseth]

Hi,

 

It is correct that there's an adjustment of the i2s clock, as explained better here:

https://github.com/nrfconnect/sdk-nrf/blob/v2.7.0-rc1/applications/nrf5340_audio/doc/firmware_architecture.rst#synchronization-module-overview

 

However, the module itself is tightly coupled with the nrf5340_audio application:

https://github.com/nrfconnect/sdk-nrf/blob/v2.7.0-rc1/applications/nrf5340_audio/src/audio/audio_datapath.c

It highly depends on other modules in the application to run properly.

 

Please also note that the USBD ISO buffers are double-buffered, so you can call this function while an on-going transfer is occurring. This will highly likely not help if the actual audio clock drifts too much, then that would still need to be adjusted.

  

Kind regards,

Håkon