Configure xk-evk-xu316 for multichannel

[AudioAddict06]

Hi,

I'm new to XMOS. I've recently started using the xk-evk-xu316 board. I've started with the sw_usb_audio project (v8.1.0) and all builds fine out of the box.

What I want to do next is configure the board to receive multichannel audio over USB 2.0 (16 channel in), and then direct each channel to a GPIO pin and into external DACs.
My question is how to configure the board for this. I have tried the build options approach (for example 2AMi10o10xxxxxx), which does build but seems to remain 2in2out. I may be completely missing the point of that sw_usb_audio package.

Help to configure this correctly would be hugely appreciated. Thanks in advance.

[danielp]

In your Makefile, you can set NUM_USB_CHAN_IN and NUM_USB_CHAN_OUT to configure the number of USB audio channels. Setting this to something larger than two will still result in your application having just two channels of audio over I2S; you would have to change the I2S_CHANS_ADC/I2S_CHANS_DAC values to alter that.

If that doesn't work for you, please could you share which configuration defines you are setting in your Makefile or xua_conf.h?

[AudioAddict06]

Thank you for the reply - legend! I had a mistake in the Makefile (NUM_USB_CHAN_IN instead of DNUM_USB_CHAN_IN). It now build and runs.

Now I have to work out the I2S_channels as I want to out put 16 channels from 16 input over USB.
I'm looking at the app_usb_aud_xk_evk_xu316_extrai2s example to see if it can be reconfigured for 16 outputs but need to work out which ports to use.

Is there any other good examples of demuxing 16 channel audio in over USB to use the GPIO pins for 16 channel out?

[danielp]

I'm not aware of any other examples of what you're looking for. Also, app_usb_aud_xk_evk_xu316_extrai2s demonstrates running I2S on pins attached to the non-audio tile for small pin-count devices.

In your case, you should have enough GPIO pins on tile 1 (audio tile) so that you don't need to cross to the other tile. For example, have a look at GPIO header J13.

Once you've selected your GPIO pins, take a look at the audio I/O port declarations.

One side-note on terminology: you said "the board to receive multichannel audio over USB 2.0 (16 channel in)" - the in/out channel counts are relative to the host rather than the device. So if you want to send sixteen channels of audio from your host to the device (and then send these to external DACs), that would be sixteen channels out.

[altman]

Hi,

Trying a similar thing - attempting to get 2 extra I2S input channels (ie one additional I2S data line) onto a QF60 package, but wanting to validate this works on the xcore.ai devkit with the BGA first. Using sw_usb_audio_9.0.0

First, a sanity check: compile and run app_usb_aud_xk_evk_xu316. Both the 1AM and 2AM binaries work as expected, 2 input channels appear in the USB descriptor and audio fed to line in is received on USB.

Next, I move to the app_usb_aud_xk_evk_xu316_extrai2s example; start by jumpering the pins as noted in the readme to get the BCLK/LRCLK/second data channel duplicated from the ADC.

This compiles and runs ok, but I only see two channels appear in the USB descriptor, which doesn't match the docs which say you get 2ch in, 2ch out (on-board codec) and another 2ch in. Looking at the code, it seems like xua_defs.h is pulled in from app_usb_aud_xk_evk_xu316, and that has I2S_CHANS_ADC set to 2 (and that's where the descriptor gets the number of channels from).

Change that to 4, and find then that the compile fails as PORT_I2S_ADC1 is not defined. I add '#define PORT_I2S_ADC1 XS1_PORT_1M' to the xua_defs.h (as this seems to be where extra_i2s.xc is expecting data from) and then I get this error:

xmap: Error: Symbol p_i2s_adc[1] is a duplicate port declaration.
xmap: Error: previously declared as p_i2s_din[0].

As a terrible hack I set PORT_I2S_ADC1 to XS1_PORT 1F (as it's not used). I can now compile & run, and see 4 channels in the descriptor. However, I see nothing on ch2/3, and if I remove the data wire going to X1D36 then there's nothing on all channels.

Poke around a bit more and see that extra_i2s.xc has EXTRA_I2S_CHAN_COUNT_IN as 2, but EXTRA_I2S_CHAN_INDEX_IN as 0 which doesn't seem right - like it'll be blatting the extra i2s input channel over the two original channels. I change EXTRA_I2S_CHAN_INDEX_IN to 2 and re-run. Yay, this now behaves as expected in that ch0/1 are always showing audio, and if I add the data in jumper between ADC_DAT and X1D36, ch2/3 also show audio.

But: I'm confused as to the config changes I needed to do. They seem reasonable, aside from the p_i2s_adc warning quoted above... as I'm very limited on pins in the QF60, do you have any suggestions as to how I should configure the example to work on such a package? There don't seem to be enough X1 single IO pins to get a second BCLK and LRCLK, especially if I need to burn another pin for the unused p_i2s_adc[1] to be valid enough for the compiler not to barf.

[Charger0]

Hi,

Trying a similar thing - attempting to get 2 extra I2S input channels (ie one additional I2S data line) onto a QF60 package, but wanting to validate this works on the xcore.ai devkit with the BGA first. Using sw_usb_audio_9.0.0

First, a sanity check: compile and run app_usb_aud_xk_evk_xu316. Both the 1AM and 2AM binaries work as expected, 2 input channels appear in the USB descriptor and audio fed to line in is received on USB.

Next, I move to the app_usb_aud_xk_evk_xu316_extrai2s example; start by jumpering the pins as noted in the readme to get the BCLK/LRCLK/second data channel duplicated from the ADC.

This compiles and runs ok, but I only see two channels appear in the USB descriptor, which doesn't match the docs which say you get 2ch in, 2ch out (on-board codec) and another 2ch in. Looking at the code, it seems like xua_defs.h is pulled in from app_usb_aud_xk_evk_xu316, and that has I2S_CHANS_ADC set to 2 (and that's where the descriptor gets the number of channels from).

Change that to 4, and find then that the compile fails as PORT_I2S_ADC1 is not defined. I add '#define PORT_I2S_ADC1 XS1_PORT_1M' to the xua_defs.h (as this seems to be where extra_i2s.xc is expecting data from) and then I get this error:

xmap: Error: Symbol p_i2s_adc[1] is a duplicate port declaration.
xmap: Error: previously declared as p_i2s_din[0].

As a terrible hack I set PORT_I2S_ADC1 to XS1_PORT 1F (as it's not used). I can now compile & run, and see 4 channels in the descriptor. However, I see nothing on ch2/3, and if I remove the data wire going to X1D36 then there's nothing on all channels.

Poke around a bit more and see that extra_i2s.xc has EXTRA_I2S_CHAN_COUNT_IN as 2, but EXTRA_I2S_CHAN_INDEX_IN as 0 which doesn't seem right - like it'll be blatting the extra i2s input channel over the two original channels. I change EXTRA_I2S_CHAN_INDEX_IN to 2 and re-run. Yay, this now behaves as expected in that ch0/1 are always showing audio, and if I add the data in jumper between ADC_DAT and X1D36, ch2/3 also show audio.

But: I'm confused as to the config changes I needed to do. They seem reasonable, aside from the p_i2s_adc warning quoted above... as I'm very limited on pins in the QF60, do you have any suggestions as to how I should configure the example to work on such a package? There don't seem to be enough X1 single IO pins to get a second BCLK and LRCLK, especially if I need to burn another pin for the unused p_i2s_adc[1] to be valid enough for the compiler not to barf.

If you need a second I2S channel, consider using a multiplexer for the clock signals or assigning them to alternate pins, but be careful not to create conflicts. As for the p_i2s_adc error, it's due to port assignment conflicts. Since XS1_PORT_1F worked as a placeholder, it should be fine, but only if it doesn’t clash with other I2S signals. Changing the EXTRA_I2S_CHAN_INDEX_IN to 2 was a good move because the example assumes two I2S input channels, and your setup requires that. If you're still getting the port duplication warning, check if you're inadvertently assigning the same port in multiple places. Overall, make sure the channel count and input assignments are consistent across the project.