Multichannel I2S

First time on the site? Say hello here!
multii2s
Junior Member
Posts: 5
Joined: Tue Jan 26, 2021 8:52 am

Multichannel I2S

Post by multii2s »

~2 years ago we had a project that required input of > 48 I2S channels, did a quick look at the market but found an appropriate solution and did it ourselves. The idea is extremely easy, enables to input ~30 stereo channels per USB port (tested upto 192 kHz sample rate for stereo I2S; should work upto 768 kHz but was not tested) and requires only the USB controller. Single board PC can process over hundred of channels. Our solution was not tested with multichannel ADCs with TDM but it should work as well resulting to 240 audio channels per USB port.
I intentionally do not provide any links in order to avoid this post being an advertisement. My question: do I miss something? Is it a problem to input >30 channels to host? Or there is no problem and it is easy to input as many channels as necessary to host without any issues? But If I take a look at the forum posts it seems to be a problem. Thanks in advance for your feedback.
User avatar
fabriceo
XCore Addict
Posts: 233
Joined: Mon Jan 08, 2018 4:14 pm

Post by fabriceo »

Hi
you have to deal with the USB 2.0 bandwidth and especially the fact that XMOS Usb Audio Application is limited to only 1kB of data every 125us (for each way in or out). so if you have 32bits word this gives a max of 8 channels at 192k, or 16 at 96k and 32 at 48k. with 16bits width you double this. as simple as that.
A check is required if the host driver can handle such number of channels. on the XU216 side, I havent seen limitations in the source code regarding the number of channels.
multii2s
Junior Member
Posts: 5
Joined: Tue Jan 26, 2021 8:52 am

Post by multii2s »

thanks for your reply; that was also my understanding that is limited to number of channels, bit depth and sample rates.

Therefore, we did it different: USB3.0 is used (bulk); current technical implementation: one USB can handle 31 channels (fully synchronous -> if you input 31 sin waves from the same source and open the streams in an audio editor all sin waves will have exact the same phase; it can be a mono, stereo channels or TDM; TDM was not tested yet) and there are no such restrictions for the sample rate and bit depth (--> 32 bit 768 kHz is possible). If the number of channels is more than 31; second USB port is used; both streams can by synchronized (because USB processing in OS is not real-time and there are delays between USB buffers) but this is not relevant for sound applications in most cases except beamforming. I tested the solution on one board pc with ~100 stereo channels and it works fine. so my question is: why do all use XMOS chips (may be due latency, energy consumption, ??) or because no one had the idea how we did it or because such requirements >= 30 channels and higher sample rates are not relevant? After we did our development, I tried to contact some companies from audio domain but didn't get any answer; therefore, I just try to understand why no one was interested in our development from a technical point of view.
fabriceo wrote: Fri Jan 29, 2021 8:24 am Hi
you have to deal with the USB 2.0 bandwidth and especially the fact that XMOS Usb Audio Application is limited to only 1kB of data every 125us (for each way in or out). so if you have 32bits word this gives a max of 8 channels at 192k, or 16 at 96k and 32 at 48k. with 16bits width you double this. as simple as that.
A check is required if the host driver can handle such number of channels. on the XU216 side, I havent seen limitations in the source code regarding the number of channels.
User avatar
akp
XCore Expert
Posts: 580
Joined: Thu Nov 26, 2015 11:47 pm

Post by akp »

May I ask, what are you trying to solve? It seems you're not using UAC2, you're probably not using XMOS, and it seems you've already achieved your goal, so that's fantastic.
multii2s
Junior Member
Posts: 5
Joined: Tue Jan 26, 2021 8:52 am

Post by multii2s »

akp wrote: Fri Jan 29, 2021 8:58 pm May I ask, what are you trying to solve? It seems you're not using UAC2, you're probably not using XMOS, and it seems you've already achieved your goal, so that's fantastic.
I am trying to say that it is possible to input the above mentioned number of I2S channels directly to host using only USB controller without FPGA, XMOS or any other chips and my question to experts in this forum: do you know such solutions/products or heard about it previously and why it will not be done in such way in audio industry where FPGA, XMOS or other chips will be used. I do not think that what I did is something new and try to understand why it is not will be done using only USB controller (e.g. 30 channels I2S->USB3 Controller -> Host) but using a XMOS chip: 32 channels I2S -> XMOS -> Host.
User avatar
akp
XCore Expert
Posts: 580
Joined: Thu Nov 26, 2015 11:47 pm

Post by akp »

The biggest potential issues I see with your implementation is that, according to my understanding:
1. Bulk transfers have built in error detection and retransmit. Isochronous transfers are best effort only, to avoid stalling the bus.
2. Bulk transfers have pretty much the lowest priority access to the USB bus, so there's a potential for issues with bus starvation. Isochronous transfers have guaranteed access to the bus.

Those are the reasons USB audio class uses isochronous transfers, and that's how class compliant implementations work (e.g. the XMOS and FPGA to which you referred). In practice your success indicates everything is probably OK given reasonable hardware, OS, drivers, etc. But that's what I see are the theoretical concerns with your approach.

So the question as to why there's a channel limit with XMOS, it's due to the USB 2.0 isochronous transfers. The maximum isochronous packet size is 1024 bytes, as @fabriceo mentioned, and the XMOS code is limited to one transaction per microframe. Now, the USB 2.0 allows more than one transaction per microframe (125 us) on high-speed -- if it's a high speed, high bandwidth endpoint it can do up to three transactions per microframe -- but the XMOS code does not support the feature to do multiple transactions per microframe. I suspect it could certainly be added (and I understand some XMOS adopters have added this feature) but it's not in the official release of the source (or maybe even in the precompiled library, I don't know).

So, to sum up, the channel limit is due to the underlying XMOS code limiting the maximum bandwidth to 1024 * 8000 = 8,192,000 bytes/sec. So you can easily calculate the channel limit at 96/32. Noting you need to be able to transfer one more sample per microframe than nominal gives max ch = floor(1024 / 4 / (96/8 + 1)) = 19 according to my calculation. That is, 19 ch/packet * 4 bytes/sample * (12 + 1) max samples/ch = 988 bytes. And for 192 ksps you should get 10 channels, maximum. Of course this assumes your OS / device driver supports that channel count. I find the Linux ALSA device drivers are better than Windows for flexibility on channel count, sampling rate, etc.
multii2s
Junior Member
Posts: 5
Joined: Tue Jan 26, 2021 8:52 am

Post by multii2s »

akp, many thanks for your detailed answer.
Though the used USB3 controller supports isochronous transfer; I chose the bulk because it seems for me to be more appropriate for my specific scenario (SDR: Zero-IF tuners and high-end audio ADCs) but the transfer type can be changed to isochronous programmatically. ALSA is also not used because it is not relevant for my scenario and the data will be directly transferred to application using libusb (latency was not an issue). I also read somewhere that ALSA has/had difficulties if the number of channels exceed30 (but I didn’t check it). At the beginning I thought that my solution can be applied for other areas and could be interesting for alternative scenarios that require multichannel I2S-input incl. audio domain.
Thanks to your answer internals and restrictions are much clearer for me why XMOS cannot be used for higher sample rates. My current understanding from the answers: for audio applications it is fully sufficient to use an existing and proven solutions based on USB2, e.g. XMOS, where drivers and libraries are available and there is no necessity to migrate to USB3 (except very low latency application scenarios but for such cases there are proven solutions based on FPGA are already available as well).

akp wrote: Sat Jan 30, 2021 4:23 pm The biggest potential issues I see with your implementation is that, according to my understanding:
1. Bulk transfers have built in error detection and retransmit. Isochronous transfers are best effort only, to avoid stalling the bus.
2. Bulk transfers have pretty much the lowest priority access to the USB bus, so there's a potential for issues with bus starvation. Isochronous transfers have guaranteed access to the bus.

Those are the reasons USB audio class uses isochronous transfers, and that's how class compliant implementations work (e.g. the XMOS and FPGA to which you referred). In practice your success indicates everything is probably OK given reasonable hardware, OS, drivers, etc. But that's what I see are the theoretical concerns with your approach.

So the question as to why there's a channel limit with XMOS, it's due to the USB 2.0 isochronous transfers. The maximum isochronous packet size is 1024 bytes, as @fabriceo mentioned, and the XMOS code is limited to one transaction per microframe. Now, the USB 2.0 allows more than one transaction per microframe (125 us) on high-speed -- if it's a high speed, high bandwidth endpoint it can do up to three transactions per microframe -- but the XMOS code does not support the feature to do multiple transactions per microframe. I suspect it could certainly be added (and I understand some XMOS adopters have added this feature) but it's not in the official release of the source (or maybe even in the precompiled library, I don't know).

So, to sum up, the channel limit is due to the underlying XMOS code limiting the maximum bandwidth to 1024 * 8000 = 8,192,000 bytes/sec. So you can easily calculate the channel limit at 96/32. Noting you need to be able to transfer one more sample per microframe than nominal gives max ch = floor(1024 / 4 / (96/8 + 1)) = 19 according to my calculation. That is, 19 ch/packet * 4 bytes/sample * (12 + 1) max samples/ch = 988 bytes. And for 192 ksps you should get 10 channels, maximum. Of course this assumes your OS / device driver supports that channel count. I find the Linux ALSA device drivers are better than Windows for flexibility on channel count, sampling rate, etc.
mmar
XCore Addict
Posts: 133
Joined: Fri Jul 05, 2013 5:55 pm

Post by mmar »

I2S is too output, then when your Controller can do Input synced to ADC, same Controller i mean cant do output with low jitter audio clock.
multii2s
Junior Member
Posts: 5
Joined: Tue Jan 26, 2021 8:52 am

Post by multii2s »

I did only input. Theoretically, the output should work as well. At the first glance, the limitation will be that IN and OUT I2S should have the same sample rate if only one USB controller is used. This is not a problem if multiple USB controllers will be used. Moreover, I am not sure about full duplex operation because my understanding of USB3 that TX and RX cannot transfer data at the same time.
Regarding jitter: we are using TCXO 12.288 MHz with following characteristics (from datasheet):
Frequency StabilityVs. Temp (-30 ~ +85°C)±2.5PPMVs.
Supply Change (±5%)±0.3PPMVs.
Load Change (±5%)±0.3PPMVs. Aging/Year±1.0PPM
Phase Noise@ 1 KHz Offset-135DBc/Hz
All other frequencies are obtained by dividing the base frequency TCXO. It is also possible to use something like SI5319 and use an external clock but I didn’t evaluate it for this application.
mmar wrote: Mon Feb 01, 2021 7:46 pm I2S is too output, then when your Controller can do Input synced to ADC, same Controller i mean cant do output with low jitter audio clock.