[linux-audio-user] Re: [linux-audio-dev] [ANN] netjack-0.11

[Nick Copeland]

>
>- most people think udp is evil ;)
>

UDP is a far better match for audio transmission than TCP. The issue comes 
does two the difference between the two protocols when it comes to packet 
loss. Assuming the loss was due to CRC errors or drops under congestion then 
TCP will recover the lost data itself. UDP will not as it has no concept of 
transmission control.

The ability of TCP to recover this loss points people in the direction of 
preferring the protocol, but this is not the case with audio. If there is 
loss of framing with audio transmission over IP then a better recovery is to 
accept the loss and resync the data streams. This is in effect what Jack 
does with audio overruns in soft mode. Relying on TCP to handle the recovery 
means that you have to wait for the resync, and that works very, very badly 
with TCP, you are likely to go into a slow start and will have the available 
bandwidth throttled down to the point where very little audio will get 
through. The only way for a TCP based audio application to deal with this 
effect (Van Jacobsen algorithm) is to have adaptive resampling rates where 
the sampling rate over the network is a function of the bandwidth available. 
Since the back off algorithm in TCP effectively throttles your available 
bandwidth then your netjack will have to adapt its resampling rates 
accordingly, or lose sync completely. Now with TCP, the protocol will 
attempt to recover all the data you sent, rather than accept the overrun and 
continue.

The use of UDP will allow you programme to define its own sampling rates, 
define its own UDP transmission rates, the application (netjack) will then 
just have to deal with drop outs, zero filling being one option for example.

>
>- it looks like i am the only one messing with BIG (16k) udp packets in
>   low latency situations under high SCHED_FIFO load.
>

If you are looking to put this application over the internet, then these 
large (or rather 'jumbo') frames are a no-go. The internet does not support 
large frames, 1480 being the largest generally accepted payload. If you send 
a jumbo frame then the nearest router to you transmitter will have to 
fragment the packet from 1x16k down to about 12x1480 byte packets. This 
negates any hardware based routing as this generally takes place in software 
running under the router OS. In short you will add a lot of overhead to your 
application: it is very likely that 12 frames of 1480 bytes would arrive 
faster than one 16K frame that has been fragmented since you will not have 
incurred the overhead on the router to fragment the jumbo. There is 
additional downside in that the loss of a single fragmented frame will 
result in the loss of the whole jumbo. The loss of a single 'small' frame 
will be that single loss only as IP is no longer responsible for reassembly 
of the fragments at the destination - your application is given that 
responsability.

Nick.

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/