Possible bug in evkmimxrt1060/usb_examples/usb_device_composite_hid_audio_unified SDK example

cancel
Showing results for 
Search instead for 
Did you mean: 

Possible bug in evkmimxrt1060/usb_examples/usb_device_composite_hid_audio_unified SDK example

Jump to solution
90 Views
EdSutter
Senior Contributor II

Hi,

I'm working with a modified version of the evkmimxrt1060/usb_examples/usb_device_composite_hid_audio_unified project and I believe there's a bug (or at least an improvement that can be made) in bm/audio_unified.c...

The application is pre-configured to run at 48kHz; but I had need to test something at 16kHz; hence, I stumbled on an issue on the USB side of things.  There are two definitions in usb_device_descriptor.h:

#define AUDIO_IN_SAMPLING_RATE_KHZ (48) and #define AUDIO_OUT_SAMPLING_RATE_KHZ (48).

I changed these (plus a few other hardware specific clock adjustments) to 16 and found that the host still thought the USB device was using a 48kHz sample rate.  I then discovered these lines in audio_unified.c:

...

g_deviceComposite->audioUnified.curSampleFrequency = 48000U;

...
g_deviceComposite->audioUnified.freqControlRange.wMIN = 48000U;
g_deviceComposite->audioUnified.freqControlRange.wMAX = 48000U;

...

 

When I changed 48000U to (AUDIO_IN_SAMPLING_RATE_KHZ *1000) my host then saw the device as a 16kHz samplerate.  

NXP Team: please let me know if you agree with this change.  I don't know the USB stack that well, so this is based on empirical observation only.

By the way, the same issue exists for bm and lite/bm.

Thanks,

0 Kudos
1 Solution
70 Views
Alexis_A
NXP TechSupport
NXP TechSupport

Hello @EdSutter,

I agree with you, you also need to modify this so the host can identify the device sample frequency. I will forward your comments to the applications team.

Best Regards,

Alexis Andalon

View solution in original post

0 Kudos
5 Replies
30 Views
AndyCapon
Contributor II

Hi Guys,

Also AUDIO_IN_SAMPLING_RATE_KHZ as an integral might not be the best way, how about 41000, 4.1 will not work there.

Is there any example code anywhere of supporting multiple frequencies set by the host?

 

Many thanks

 

Andy

0 Kudos
26 Views
EdSutter
Senior Contributor II

Hi @AndyCapon ,

I started down the path of supporting multiple sampling rates, but quickly backed off (for now) when I realized that this opens up a whole new can of worms (as best I can tell)...

1. There are buffers whose sizes are based on the fixed definition of the sampling rate; so, buffers would have to either be statically allocated to their worst case or dynamically allocated.

2. The descriptors would have to show the host what sampling rates are supported.  I've been working on my project several months and have to admit I still know very little about USB and descriptor setup.  Sure would love to find some good documentation on that somewhere.

3. Depending on your codec, different sampling rates may require different divisors to be used when configuring the audio PLL.

4. Etc...

Please update me if you disagree (I'm still on the learning curve); but I believe all of the above are correct.

Ed

0 Kudos
23 Views
AndyCapon
Contributor II

Hi Ed,

I agree totally, generally USB should be renamed COW for Can Of Worms!

I have fractional rates like 44.1 and 88.2 going now with a loopback but not with the actual audio hardware on the board (1170) as the DMA stuff will need work.

I need to look at getting multiple rates going so when that is working with loopbacks I will post the changes for you.

Cheers

 

Andy

 

Andy

 

 

 

 

 

 

0 Kudos
71 Views
Alexis_A
NXP TechSupport
NXP TechSupport

Hello @EdSutter,

I agree with you, you also need to modify this so the host can identify the device sample frequency. I will forward your comments to the applications team.

Best Regards,

Alexis Andalon

View solution in original post

0 Kudos
59 Views
EdSutter
Senior Contributor II

Great, thanks!

0 Kudos