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

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