usb audio app randomly change I2S justification

Discussions about USB Audio on XMOS devices
Posts: 19
Joined: Wed Feb 03, 2021 9:06 pm

usb audio app randomly change I2S justification

Post by bonelli »


I successfully ported the USB audio SW to my custom board. Working with linux and windows with a single stereo output port, 192kHz/24b with a TI DAC.

For the second time, when looking the I2S signals at the scope I noticed some strange behavior on the data line:


Windows is configured for 192k/24bits. Today, the XMOS output I2S data right-justified! I did not do any modification on the software. Yesterday, the same code was correctly outputting 24 bits data in normal mode (left-justified).

I tried to reboot the board, replug the USB cable, data is still right-justified, with the MSB at 0x00 or 0xFF (sign extent ?).

Any ideas ?
Thank you

Posts: 19
Joined: Wed Feb 03, 2021 9:06 pm

Post by bonelli »

Problem solved : the volume was set at 50%. But I wasn't aware about that:

- Windows volume at 100% : 24 bits data on the 3 first byte of the 4 I2S bytes.
- Windows volume lowered : the data is not lost, we can found it on the 4th byte of the I2S line.

My codec chip is 24 bits and only uses the 3 first bytes. It also has an analog volume control placed just after the DAC. So, for volume control, to keep dynamics, I suppose the best thing to do is to always set the computer volume at 100% and only use the analog volume control located in the DAC device.
User avatar
XCore Addict
Posts: 213
Joined: Mon Jan 08, 2018 4:14 pm

Post by fabriceo »

Hi Bonelli

by default, the USB application is configured to expose a 24bit "Alternate1" to windows but using 4 bytes of data.
this explains why you get the 32bits from windows.
you can change that if you will with these 2 lines somewhere in your customdefines.h:

Yes, you will get good results by using the volume control integrated in the chip, but this is specially interesting for DSD streams. for PCM you will not notice any difference (at least with measurement devices, but may be some golden hears would)

Implementing the volume control in the chip will require a specific I2C master task somewhere and to intercept the USB commands sent to the unit FU_USBOUT that you can see in audiorequest.xc. you also need to master the communication between tasks using interfaces especially if the i2c port is on tile0...

best of luck, this is a rewarding journey