High-bandwidth endpoints

[michele-perrone]

Hi,

I was reading through the XMOS forum and I found the information that lib_i2s currently supports up to 10 channels at 192kHz/32bits, which confirms Table 4 of the USB UAC2 guide:

I was wondering: are there any plans for implementing high-bandwidth endpoints in lib_xud? That would bring more than triple the bandwidth compared to what we have now, enabling a lot more I/O channels for lib_i2s.

Thanks!\ Michele

[xross]

Assuming asynchronous USB Audio Class 2.0 at high-speed, standard bandwidth endpoints are already capable of sustaining simultaneous input and output at 192kHz with a maximum of 10 channels at 32 bit (this would be 1000 bytes per packet and the limit is 1024)

There is no fundamental reason why high-bandwidth endpoints cannot be supported on the xcore (indeed there has been some proof of concept work in the past), however, there are yet to be much commercial call for the channel-counts/sample-rates they would allow.

Will keep you informed as to any update.

[michele-perrone]

Hello Ross, many thanks for you feedback.

At Weiss Engineering we are investigating the possibility of using X-MOS chips for the next generation of our audio interfaces in the pro-audio segment. However, the current channel count is a limiting factor in comparison to what Firewire had to offer. For example, our AFI1 supports 24 in/24 out at 44.1 and 48 kHz, 16 in/16 out at 88.2 and 96 kHz, and 8 in/8 out at 176.4 and 192 kHz. In order to reach the same channel count, high-bandwidth endpoints would be needed.

Kind regards, Michele

[xross]

Michele, assuming 32bit audio and an asynchronous device the following are the maximum channel counts that can be achieved with standard endpoints:

48kHz: 42 in/42 out 96kHz: 19 in/19 out 192kHz: 10 in/10 out

For example, 192kHz requires 192000/8000 = 24 samples per packet (where 8000 is the usb micro frame rate). We need to add one for asynchronous packet size changes so 25. 25 * 4bytes = 100 bytes per channel per microframe

1024 bytes (max packet size) / 100 bytes = 10.24 channels

There may, of course, be other limitations the reduce channel count other than USB bandwidth (I/o count, MIPS to deliver I2S etc)

High-bandwidth endpoints would, in theory, allow approx unto *3 channels, so approx 30 channels at 192.

[michele-perrone]

Hi Ross, maybe I didn't understand the table above well, or I didn't express myself very clearly. Probably I should have written:

44.1 and 48 kHz: 48 channels (24 in + 24 out) 88.2 and 96 kHz: 32 channels (16 in + 16 out) 176.4 and 192 kHz: 16 channels (8 in + 8 out)

Your calculation suggests that at 192kHz, there is a total of 10 channels available: this means, for example, 5 in + 5 out. Is this correct?

[xross]

As per the line above the table: Note that since an isochronous endpoint provides unidirectional data flow the following channel count values are per audio direction.

[fabriceo]

Hello, I d like to reinforce this enhancement request. There is more and more appetite for DSD256 and PCM384k which is not possible for 8 channels USB DAC due to the 64MBit limitation. So it is not possible to feed a beast like ES9038 with its maximum capabilities. Using both PIDDATA0 & PIDDATA1 is needed to overcome this. this will probably require a specific chan-end for each DATA0 and DATA1 flow and two separate buffer tasks to accommodate the required mips (guessing)... also it is unknown if Thesycon driver and Linux/Macos driver can deal with this (either DSD256x8 or 384Kx8 or 192kx16 outs + ins).