How to receive 16 I2S channels

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
ffomich
Experienced Member
Posts: 119
Joined: Mon Sep 15, 2014 1:32 pm

How to receive 16 I2S channels

Postby ffomich » Thu Nov 12, 2020 9:28 am

Hi guys,
my goal is to receive 16 I2S channels from 16 audio sources.
The USB Audio Reference project operates with I2S via 1-bit ports.

Does anyone try to connect 4*I2S channels to 4-bit port or 8*I2S channels to 8-bit port and get audio data? Yes, in this case, I have to modify audio.xc and use many bit operations.
Is this connection method possible?

If NO, do I need to use something like N*I2S -> TDM converter and send TDM to XMOS?
User avatar
CousinItt
XCore Addict
Posts: 191
Joined: Wed May 31, 2017 6:55 pm

Postby CousinItt » Thu Nov 12, 2020 5:16 pm

Hi,

I developed an I2S interface using 4-bit ports. It's not all plain sailing, for two reasons:

1) The data is received from, and transmitted to, the ports as a block of interleaved bits, so it's necessary to use additional code to convert between data formats. See the app note AN10129 for more info on this. I found it necessary to modify the code slightly.

2) The shift registers for ports are limited to 32 bits. If you use a multi-bit port, this can mean having to transfer data to/from the port several times during each audio word (e.g. four times for 32-bit data and four-bit port). This can allow a much shorter window for transferring data between the I2S controller and the source/sink for the audio data, or means that you need to sequence things more carefully.

Both of these can be a real pain if the data rate is high, and if you have to deal with these problems it becomes clear how much easier it is to use single-bit ports. However if you're running at fairly normal data rates this method can work well.

The only thing I'd like to see (and this is getting a bit off topic) is support for an interface that exchanges pointers to data blocks rather than transferring all the data via channels. Again, this would save time when passing a large number of audio channels with a high data rate. Maybe a conversation for a separate thread.
ffomich
Experienced Member
Posts: 119
Joined: Mon Sep 15, 2014 1:32 pm

Postby ffomich » Fri Nov 13, 2020 11:52 am

Hi CousinItt,
thank you for your detailed answer. I'm going to receive I2S @ 48k.
User avatar
CousinItt
XCore Addict
Posts: 191
Joined: Wed May 31, 2017 6:55 pm

Postby CousinItt » Fri Nov 13, 2020 1:18 pm

In that case you should be fine. I suggest you review the lib_i2s implementations in detail before trying your own. The latest version is on the xmos github. For some reason xTimeComposer can only get an older revision.
nick
Active Member
Posts: 40
Joined: Tue Jan 07, 2020 10:35 am

Postby nick » Sat Nov 14, 2020 12:24 pm

Hi,
a question a bit off-topic: I noticed there's quite a difference between versions that xTimeComposer downloads and the versions on github.
Are the libraries on github still compatible with XMOS application notes? Or if someone uses application notes it's better to use xTimerComposer downloaded libraries?
User avatar
CousinItt
XCore Addict
Posts: 191
Joined: Wed May 31, 2017 6:55 pm

Postby CousinItt » Sat Nov 14, 2020 3:34 pm

I think the answer is that it depends. The more difference between the revision of the app note and the revision on github, the more changes there will be, so check the revision notes to see what's new.

Note that the github repository for each library also contains the documentation as restructured text. I've tried generating a document from the rst file in the lib_i2s/doc folder, using the python rst2pdf package. It spat out a document, not perfect but good enough to see the change list and a rough approximation of the app note contents. Perhaps someone else can comment on the conversion process.

Who is online

Users browsing this forum: No registered users and 1 guest