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

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. 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/