AVB projects: Multi channel audio dist. and mixing with DSP

[mark]

I am not an engineer or developer but an entrepreneur with a little engineering training and experience. Our company has developed a digital sheet music management and display system with integrated multichannel mixing called SamePage.

We broadcast 32 channels of 24bit audio at 48khz over a standard Ethernet network and then pull this audio off the network and mix it anywhere on the network via Windows with sub 3ms latency.

We are looking to eventually move to the new AVB standard. I am looking to understand what has been accomplished using xmos chips in conjunction with multichannel audio (24-48 channels). I have seen some of the application briefs on the AVB development kit. Has anyone experimented with how many channels of hi quality audio can be processed and mixed?

Jonathan mentioned that this seems feasible and some of the development might already be done. Is anyone working on anything like this?

Ideally I would like to have two primary devices. One would take 16 channels of I2S and place it on the AVB network. The other device would input 2 channels onto the AVB network and output 2 independent channels of mixed audio (mixed from the entire collection of channels). I would also like to do some DSP to each channel.

The XMOS AVB Application Guide has been helpful, but I still want to know more.

I would appreciate anyone's thoughts and input.

[jonathan]

The best place to look for audio-related applications is here:

http://www.xmos.com/applications/audio-systems-and-usb

Hopefully someone here will be able to answer your question more specifically...

[davelacey]

I'm not sure how up to date the documentation you are looking at is. The application guide has been merged into the design guide for the latest release. You can find the documentation here:

https://www.xmos.com/published/avb-design-guide

You would be able to output a 16-channel AVB stream and broadcast it to all the other units. This would take ~30Mbit/s of bandwitdh (see the design guide section 9). The other units can input this 16 channel stream and pick channels from it to go to the mix.

Are the other units outputting onto the AVB network or just receiving (and mixing with their own local sources)?

The mixing would have to be done by adding specialized code into the AVB framework between the listener sample buffers and the h/w interface. This would be quite simple code, however.

Dave

[mark]

Thanks for the reply and the information. We are ordering the development kit this week and should be getting started soon.

The listening units would be listening to multiple streams and mixing the levels of each channel for one or two outputs. There would be no local sources to mix with. Eventually we might use them as talker and listener nodes on a larger network.

Does anyone know if the XAI audio interface is done yet? The website says the middle of January but I haven't seen it on GigiKey.

[paul]

For the XAI I reccommend you contact XMOS directly for information. Email support (at) xmos (dot) com

Regards,

[lilltroll]

I just add a small observation here.

I added threads, so I had 8 (maximum) threads on one Core.
Thereafter I tested with the 11.2 MHz and 25.6 MHz masterclock with the different fs up to 192 kHz - generating a B_clock up to ½ * 25 MHz at 192 kHz. The (one) thread handling the I2S com. (including taking care of the transfered data) was never starved out of time at any speed - even when the threadspeed was reduced to 50 MHz due to 8 threads.
The XMOS chip is running as a slave in the example - so it must respond back in time to the CODEC - all the time during the communication and transfer/recieve the data to 4 different 'XMOS'-channels meanwhile ('XMOS' channels: L-DAC,R-DAC,L-ADC,R-ADC)

It does not use the (as I see it, the more easy) method with the CODEC as a slave, where the master can burst out all the data for one stereo sample to the CODEC at any speed* taking advantage of the CODECs internal buffer, and thereafter have a lot of time to take care of the data until the next audio clock sample happens.

Using several CODECs in a solution with one master and several clock sync. slaves, or changing from internal to external clock sources from S/PDIF - I guess the XMOS chip will be able to handle many different senarios with determenistic processing and very short latency without the need of large external FIFO buffers.

*Any speed with a period time >30 ns or thatever maximum-speed the CODEC supports.