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

torbenh at gmx.de torbenh at gmx.de
Mon Apr 17 08:26:30 EDT 2006


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



More information about the Linux-audio-user mailing list