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
225 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
205 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
6 Replies
97 Views
EdSutter
Senior Contributor II

@Alexis_A ,

I'm not sure if I need to create another post for this, but I'm pretty sure I found another bug in the USB audio stuff (same SDK)...

I'm trying to understand how the feedback endpoint works (still quite blurry) and noticed that the function USB_DeviceAudioUnifiedInit() in audio_unified.c calls

AUDIO_UPDATE_FEEDBACK_DATA(audioFeedBackBuffer, AUDIO_SAMPLING_RATE_TO_10_14);

regardless of the USB speed (High or Full).  Since there are so many other places in the code that make the distinction between High and Full, I'm pretty sure this call should be using AUDIO_SAMPLING_RATE_TO_16_16 if the device is High speed.  This is clarified in section 5.12.4.2 of rev2 of the usb spec (bottom of pg 74).

Please let me know if you agree, 

@AndyCapon, I'm adding you to the list just so you're aware of this (assuming you didn't already catch it).

Ed

Update:

Note that I am still not convinced that the feedback mechanism  used in audio_unified.c is even correct.  As best I can tell, the spec says that the feedback value is supposed to be the number of samples per microframe measured (formatted in fixed point arithmetic to allow for a fraction); but the code that updates the value doesn't seem to do that.  Plus, the line I mentioned above just writes the sample rate/1000 into the feedback buffer.  This doesn't make any sense to me.... still very confused.

Update2:

Just realized that in addition to what I said above, the value of AUDIO_SAMPLING_RATE_TO_16_16

should actually be ((AUDIO_OUT_SAMPLING_RATE_KHZ/8) << 13) because the microframe rate is 8K not 1K.

0 Kudos
165 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
161 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
158 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
206 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
194 Views
EdSutter
Senior Contributor II

Great, thanks!

0 Kudos