On Mon, Apr 17, 2006 at 01:42:36PM +0200, Nick Copeland wrote: > > > >- 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. its all implemented and working. TCP is not an option currently. > > > > >- 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. i generally dont have the uplink bandwidth to make netjack use big udp packets over internet. with my uplink capabilities is resort to heavy downsampling reducing packet_size below 150 bytes. there seems to be some (unnecessary) latency added when using big udp packets on a LAN. i am talking about a LAN here. and i really think that big UDP packets should just work like small packets on a LAN, where the kernel is handling fragmentation and defragmentation. but this seems not the case. i have yet to test the performance with fragmentation inside of netjack.... > > Nick. > > _________________________________________________________________ > Don't just search. Find. Check out the new MSN Search! > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language
