32-bit USB Audio

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
User avatar
jjlm98
Member++
Posts: 31
Joined: Tue Aug 26, 2014 11:00 pm

32-bit USB Audio

Post by jjlm98 »

Hi all - apologies if this has been asked before, as I imagine it's a common question. Should I expect the USB Audio reference design firmware to support 32-bit samples over I2S by default? If not, what are the steps to change this?

Section 7.1.7.1 of the USB Audio Design Guide seems to imply that 24-bit sample depth is default, and offers some #defines to change this, but the notes underneath are not quite clear to me, particularly the description of "alternates."


User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am

Post by infiniteimprobability »

24b is default. You can change it to 32b by setting the defines mentioned in 4.5.1, 4.5.2 of the user guide.

See build 2ioxs_32b4_24b3_16b2 of app_usb_aud_xk_u8_2c for an example of setting these via the Makefile.

Which bit about alternates is unclear? Alternates are generally set to different bit resolution, which get selected when you choose 16b or 24b (or 32b) audio from the driver control panel. The standard ref design supports up to 3 (although it could be set to less), but that could be extended easily enough by changing EP0 and descriptors.
User avatar
jjlm98
Member++
Posts: 31
Joined: Tue Aug 26, 2014 11:00 pm

Post by jjlm98 »

Thanks infiniteimprobability - your added detail has helped me understand. The language I did not comprehend was on page 76 under the description for STREAM_FORMAT_OUTPUT_1_RESOLUTION_BITS:

"Note, 24 on the lowests alt in case of OUTPUT_FORMAT_COUNT = 1 leaving 24bit as the designs default resolution."

I guess it's simply saying that reducing OUTPUT_FORMAT_COUNT from default of 2 down to 1 simply forgoes the option of 16-bit resolution normally available in the default case?

Second, under the descriptions for STREAM_FORMAT_OUTPUT_N_DATAFORMAT, I'm unclear where the document defines the default as "UAC_FORMAT_TYPEI_RAW_DATA when Alternate N is RAW/DSD else UAC_FORMAT_TYPEI_PCM". I interpret this to say that the default format depends on the format (cyclical statement).

Apologies for the late reply!
User avatar
jjlm98
Member++
Posts: 31
Joined: Tue Aug 26, 2014 11:00 pm

Post by jjlm98 »

After studying devicedefines.h, I understand what is meant by the notes.

Can anyone suggest a way to test 32-bit traffic? I normally use the ASIO interface of an Audio Precision APx analyzer to test USB-to-I2S, but the 8 LSB's are truncated (I'm working with Audio Precision to understand if this is a limitation with the instrument, incorrect setting in Windows, etc).

In the meantime, I've used Audacity to generate a sine wave, and exported it to a WAV file using 32-bit signed PCM encoding. When the waveform is played from a host Mac, I see all 32 bits of the samples toggle on the XCore "DAC" outputs. However, when the same waveform is exported using 24-bit signed PCB encoding, I still see the 8 LSBs toggle - so I'm not sure if I'm using Audacity properly. Is there anything else I can try?
User avatar
Ross
XCore Expert
Posts: 966
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

OS X seems to do this - it fills in all the bits up to SlotSize and seems to ignore bitResolution.

You could set the slot size to 3 bytes, you will loose some performance in the un-packing though..
User avatar
Ross
XCore Expert
Posts: 966
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

jjlm98 wrote:Thanks infiniteimprobability - your added detail has helped me understand. The language I did not comprehend was on page 76 under the description for STREAM_FORMAT_OUTPUT_1_RESOLUTION_BITS:

"Note, 24 on the lowests alt in case of OUTPUT_FORMAT_COUNT = 1 leaving 24bit as the designs default resolution."

I guess it's simply saying that reducing OUTPUT_FORMAT_COUNT from default of 2 down to 1 simply forgoes the option of 16-bit resolution normally available in the default case?
The Alternatives are listed as 24, 16, 32, rather than ascending order as you might expect. This is because we figured most people will only want one format and this is most likely to be 24bit.

Actually I think all our designs currently default to 16+24bit to allow computability with a whole range or Android powered devices so ascending order would have probably been fine in the end...
User avatar
jjlm98
Member++
Posts: 31
Joined: Tue Aug 26, 2014 11:00 pm

Post by jjlm98 »

Thanks Ross for the follow-up.