Multi-channel LC3 decode + concurrent data pipe on nRF5340 Audio DK

[gzav]

I am looking to use the nRF5340 Audio DK for a POC and I have a couple of questions:

(1) this POC requires to stream multi-channel LC3 Audio (i.e., more channels than the 2 channels of a stereo Stream -- typically 4 to 8) to the nRF5340, which will decode them and then pass those decoded channels to another device  [ackowledging that nRF5340 doesn't support TDM, so we'll have to find a way round this, through encapsulation or whatever].

> Can you confirm your Audio LE / LC3 SDK supports multi-channel encoding and decoding ? Do you see any blocking point ?

(2) Plus, is it technically feasible to concurrently use LE Audio and a custom GATT profile (or a proprietary serial BLE profile), to use as a bidirectional data pipe for control data ?

Thanks

[haakonsh]

(1) this POC requires to stream multi-channel LC3 Audio (i.e., more channels than the 2 channels of a stereo Stream -- typically 4 to 8) to the nRF5340, which will decode them and then pass those decoded channels to another device  [ackowledging that nRF5340 doesn't support TDM, so we'll have to find a way round this, through encapsulation or whatever].

1. Do you need more than 8 channels? 
   
   
2. What's your minimum bit-rate requirement for each channel when at maximum amount of channels? 
   
   
3. When you say "stream... to the nRF53" do you mean over radio or physical interface?
   
   
4. What does TDM mean in this context?
   
   

> Can you confirm your Audio LE / LC3 SDK supports multi-channel encoding and decoding ? Do you see any blocking point ?

I'll ask the devs about the number of channels our stack support, from our docs it looks like there's only 2 (1 CIG with 2 CIS).  

(2) Plus, is it technically feasible to concurrently use LE Audio and a custom GATT profile (or a proprietary serial BLE profile), to use as a bidirectional data pipe for control data ?

I don't think that should be an issue as long as the throughput and latency requirements for those services are kept low.

[gzav]

Thanks for your feedback. Here are my answers:

(1) 8 channels would be sufficient at present.

I guess what I need is indeed support of up to 8 CIS on a single CIG (if my basic understanding of LC3 is correct).

(2) Each channel at 48Kbps and 24bits per sample before encoding would be good.  I'm not sure what encoded LC3 bit rate makes most sense to assume in these conditions. I believe 8 such channels could fit with satisfactory audio quality within well under 1Mbps but please correct me if I'm wrong. There is some room for spec adjustment if needed.

(3) I mean there would be an encoding side (most likely based on nRF5340 Audio DK too) sending multi-channel LC3 over the BLE radio link, received by a Rx nRF5340  Audio DK doing the LC3 decode and providing the decoded audio channels to another chip connected to it

(4) in this context TDM refers to an audio Time Division Multiplex interface, a standard serial audio interface to transfer PCM data -- essentially an enhancement of the classic I2S interface, able to carry more than 2 channels

[haakonsh]

1. I'm afraid 8 CIS's are not possible with our stack at the moment, but I've seen some PRs for Zephyr's BLE Controller testing more than 2 CIS's. I'll ask our devs what we're working on.
   
   
2. The on-air bit rate is not really the issue, I think it's the CPU overhead with regard to LC3 codec and scheduling difficulties with CIS links that is the main issue. 
   
   "Each channel at 48Kbps and 24bits per sample before encoding would be good."
   Do you mean 48 kbps or kHz? If 48kbps, then the sample rate would be very low. 
   
   
3. To rephrase your use case: One nRF53 receives and encodes a TDM PCM stream of 8 audio channels, then transmits these channels as 8 CIS to a single nRF53, who decodes and transfers the TDM PCM stream to a single device. Is this correct so far?
   
   I'm a bit confused as I struggle to grasp the use-case. As far as I understand 'POC' is essentially using the cellular network as a transport instead of long range radios, where the intended use-case is a typical 'push-to-talk' radio communication network.
   
   Why do you need to pipe 8 channels trough a single BLE point-to-point link, vs a star network where 1 device communicates to 8 devices directly? 
   
   Also, do you need bi-directional audio, ie, mic? Do you need stereo or will mono work?
   
   
4. Yeah, that's gonna be tricky. Techically you could fit 8x 16bit 24kHz stereo into the nRF53's I2S, but the frame synch signal might be tricky. If the nRF53 runs as the master and the slave accepts a frame synch signal that is 4x faster (regular LRCK), then the TDM interface will be trivial to implement on the nRF5340 side, as you'd just need to pack the I2S buffer with the TDM PCM as if it were 32bit 96kHz stereo PCM, with 4x the number of samles.