[linux-audio-user] IP audio transport

[Dan Mills]

On Wednesday 21 September 2005 02:12, Benjamin Racher wrote:
> I have also been searching for a solution to IP audio tranport
> mechanisms (over ethernet) as well, but have only found cobranet and
> ethersound as Dan mentioned, both of which appear to be propietary
> formats. I experimented with using jack.udp a while back, but it seems
> like it would hardly be sufficient for transferring multiple channels of
> audio (say 16 like cobranet). Perhapse the linux community can start to
> develop and open-source set of standards that could be used for
> transporting uncompressed audio over ethernet, perhaps using regular
> ethernet adapters?

Over a dedicated 100Mb/s network (and assuming we go for raw ethernet packets) 
I make it that with a 100Mb/s network card, running a point to point link at 
the link layer a 1500 byte payload uses a 1536 byte frame. 

That gives a maximum frame fate of 10^8 / (8 * 1536) =  8138 frames per second 
giving a payload bandwidth of  around 12MB/s.

A single 48K 32 bit sample stream will tie up  192KB/s so we can theoretically 
ram 62 channels of audio down that link. Going to a more reasonable 24 bit 
format, we can get well over 64 channels and some control data down a single 
point to point 100 Mb/s ethernet link.

Assuming we were really going for it, and trying for say 64 channels at 24 bit 
packed,  then a single audio frame is 3 * 64 = 192 bytes and we can fit 
around 7 audio frames into a ethernet frame. Call it 6 to give space for some 
control data. 

So at an ethernet frame rate of 48000/6 = 8000 ethernet frames a second we can 
transfer 64 channel 24 bit 48Khz audio over the wire. Obviously no soundcard 
can support a period of 6 frames, so there would have to be some buffering at 
the receiver and not a lot else could use the link at the same time....

Never the less it could work (and particularly where workclock is available) 
it might even be useful.

Now add a full duplex ethernet link into the mix.... 

> Could we write a protocol for transporting audio that wouldn't get
> bogged down by traffic from other protocols, or would this even be a
> problem (I'm still learning about how IP works...)

probably not at this sort of performance level, besides there just is not that 
much spare bandwidth!

Regards, Dan (Who has far more projects then he does time!).